The .git directory was missing the HEAD file (which also must contain a ref; at least "ref: refs/"). I don't think this requirement was just introduced in 1.8.2 though.
Oh man, does this ever help me. Seriously, this is the way to learn Git. Following tutorials and entering commands means you have to stick to a very specific workflow because if anything goes wrong with the black box you're just out of luck. You engage panic mode, git is broken and you might as well delete all your work, clone the repo again and start over because you don't have the vocabulary to even explain what's wrong. It might take a bit more time and effort to learn Git from a lower level, but I think this is absolutely necessary for working with Git in any way.
Minimal required .git content has 2 empty directories {objects, refs} and a file {HEAD}, with HEAD having "ref: refs/heads/master" string as its content. After creating above, git status won't throw an error.
Great talk. Learned a lot about git internals from this talk. I wish your initial attempt of creating .git sub folders to trick 'git status' worked. Did you figure out what additional items you had to add to make 'git status' happy?
***** Yep.. I saved hundreds of hours by watching at 2x. Besides, some videos are way to slow for my taste and I typically tend to lose focus. Most of the time I watch them one time at 2x, but occasionally I do have to watch them again at 2x. IMO if you are to spend the same amount of time watching a video presentation you can fixate the information better if you watched it 2 times at 2x than one time at 1x. I like to think of it as: the first pass is the familiarity pass, the second is the detail pass.
QuantumFractal I do this too. Sometimes I'll slow down to 1x if they go over something particularly quickly or I have trouble hearing a small bit of it.
+QuantumFractal I watch at 1.5x (sometimes 2 if it's way too slow). I don't have the patience to rewatch the entire thing, so I just skip back if needed and drop to 1x.
great lecture ... btw .... what git terminal is Tim using to use the tree command, as git bash v1.9.4.msysgit0 doesn't seem to be accepting this command???
That is the issue with Git - questionable system design. I mean - If one needs to teach details of "under the hood" mechanics of a tool for people to get it, then it is not an intuitively useful tool. But yes - Git is the most beautiful of ALL UGLY version control thingies we have.
I really don't think you need to know the details of the underlying system. And if you find all these version control systems to be ugly, you must have a concept that you think is "beautiful". If you have a better way of doing version control, why don't you create one?
I disagree with this statement. Git's design is very elegant! And as the speaker pointed out, there's even some software engineering insights to be gained from it! At least a handful of other VCS tried to tackle the same problem before Git and they all perished upon its arrival and adoption. When was the last time a piece of software with already well-established competitors was able to take over the industry like this? Many good tech products don't make it because getting people to change is really, really hard!
You only have to know the "marble" commands. The "plumbing" you will only know when your git goes kaputt. Instead of trying to learn plumbing you may call the plumper. Call me - for instance :-)
If git requires people to 'look inside the box' sometimes to get it to work, it means it sucks. It is typical that an uber geek create git. Great coders are crap designers (but they THINK they are good designers...). Have you ever seen a website created by a coder!? Eek!
It's like looking under the hood of my labo - I do not have a clue how it works - but I would never tell anyone it sucks :-) For me it is good enough to drive and to be fast. I only have to know the plumbing when it breaks in the middle of a race and no plumber around to yell at to get it fixed :-)
a good presentation and the best explanation of `git rebase`i've seen so far
Excellent talk, learned so much about git internals. Literally the best video on git internals.
The .git directory was missing the HEAD file (which also must contain a ref; at least "ref: refs/"). I don't think this requirement was just introduced in 1.8.2 though.
Oh man, does this ever help me. Seriously, this is the way to learn Git. Following tutorials and entering commands means you have to stick to a very specific workflow because if anything goes wrong with the black box you're just out of luck. You engage panic mode, git is broken and you might as well delete all your work, clone the repo again and start over because you don't have the vocabulary to even explain what's wrong. It might take a bit more time and effort to learn Git from a lower level, but I think this is absolutely necessary for working with Git in any way.
Fantastic talk, learnt alot, now I can feel more confident in rebasing. Thanks for sharing :D
This is THE best video on git, thank you so much Tim great tutor.
9:42 For anyone wondering, the `watch` command strips off the non-printing box drawing characters that `tree` uses.
Heh, "the detached HEAD state, not as bad for git as it is for you" :)
I think the joke completely flew over the audience's HEAD :)
This is actually really helpful. Thanks for the video.
+Dampfaeus Also a nice question: "How many of you rebase..." "... with confidence" *gg*
Masterful. This was a tour de force.
Minimal required .git content has 2 empty directories {objects, refs} and a file {HEAD}, with HEAD having "ref: refs/heads/master" string as its content.
After creating above, git status won't throw an error.
Great talk. Learned a lot about git internals from this talk. I wish your initial attempt of creating .git sub folders to trick 'git status' worked. Did you figure out what additional items you had to add to make 'git status' happy?
Awesome talk. but what exactly are the deltas?
55 minutes worth spending (or 27 at 2x speed) :) Awesome presentation!
I didn't even think watching a video at 2x speed would be a good idea till now.
haha
***** Yep.. I saved hundreds of hours by watching at 2x. Besides, some videos are way to slow for my taste and I typically tend to lose focus. Most of the time I watch them one time at 2x, but occasionally I do have to watch them again at 2x. IMO if you are to spend the same amount of time watching a video presentation you can fixate the information better if you watched it 2 times at 2x than one time at 1x. I like to think of it as: the first pass is the familiarity pass, the second is the detail pass.
QuantumFractal I do this too. Sometimes I'll slow down to 1x if they go over something particularly quickly or I have trouble hearing a small bit of it.
+QuantumFractal I watch at 1.5x (sometimes 2 if it's way too slow). I don't have the patience to rewatch the entire thing, so I just skip back if needed and drop to 1x.
Who is the speaker? He is excellent!
great lecture ... btw .... what git terminal is Tim using to use the tree command, as git bash v1.9.4.msysgit0 doesn't seem to be accepting this command???
Can someone breakdown/explain what Tim is explaining 32:07?
Jump to 9:15 if you just want to see the update script.
Any video which focuses on the beginner aspect of git?
Weird question, but does anyone have any idea what font he is using in the console?
Pardon my ignorance, but was it python he was using to write the while loop?
Nope, it's just bash.
No it's not, it's zsh.
I think it's monospace Monaco. ( which is the default monospace font for mac )
Also, the simplest way to revert a merge would be to use:
git reset --merge ORIG_HEAD
anyone know why what he first tried with hash-object didnt work?
great talk!
Thanks a lot!
Keep up the good work :)
Fixup discads the log message of the commit squashed, so I think a better option is to just use fixup instead of squash 50:40
🙏 🙏 🙏 thanks!!
Very entertaing talk.
Thanks.
Am I the only one that thinks he sounds like Louis CK?
32:44
you can do better at vim at 51min.
That is the issue with Git - questionable system design. I mean - If one needs to teach details of "under the hood" mechanics of a tool for people to get it, then it is not an intuitively useful tool. But yes - Git is the most beautiful of ALL UGLY version control thingies we have.
I really don't think you need to know the details of the underlying system. And if you find all these version control systems to be ugly, you must have a concept that you think is "beautiful". If you have a better way of doing version control, why don't you create one?
I disagree with this statement. Git's design is very elegant! And as the speaker pointed out, there's even some software engineering insights to be gained from it! At least a handful of other VCS tried to tackle the same problem before Git and they all perished upon its arrival and adoption. When was the last time a piece of software with already well-established competitors was able to take over the industry like this? Many good tech products don't make it because getting people to change is really, really hard!
You only have to know the "marble" commands. The "plumbing" you will only know when your git goes kaputt. Instead of trying to learn plumbing you may call the plumper. Call me - for instance :-)
git sucks so hard
Great talk. Shame about the way he swallows water so noisily.
😆 @21:18 here you go buddy
This was not helpful for me.
If git requires people to 'look inside the box' sometimes to get it to work, it means it sucks. It is typical that an uber geek create git. Great coders are crap designers (but they THINK they are good designers...). Have you ever seen a website created by a coder!? Eek!
I dunno if you are aware but git holds nearly 80% of market share. Been using git for years and I never had to look in .git folder.
It's like looking under the hood of my labo - I do not have a clue how it works - but I would never tell anyone it sucks :-)
For me it is good enough to drive and to be fast. I only have to know the plumbing when it breaks in the middle of a race and no plumber around to yell at to get it fixed :-)
Poorly thought out presentation. Not useful for developers who want to learn git. If he really is a trainer, he's a bad one.