I disagree with the general conclusion - I think it’s very easy to understand*: each repo has a graph of commits. Each commit includes the diff and metadata (like parent commits). There is a difference between you repo seeing the state of another repo (fetch) and copying commits from another repo into your repo (merge; pull is just a combination of fetch and pull). Tags are pointers to specific commits, branches are pointers to specific commits that get updated when you add a child commit to this commit. That’s a rather small set of very clear concepts for such a complex problem.
I also disagree with a lot of the reasoning. Like “If a commit has the same content but a different parent, it’s NOT the same commit” is not an “alien concept”. When I apply the same change to different parents, I end up with different versions. Which would be kinda bad for a Version Control System.
“This in turn means that you need to be comfortable and fluent in a branching many-worlds cosmology” - yes, if you need to handle different versions, you need to switch between them. That’s the complexity of what you’re doing, not the tool. And I like that Git is not trying to hide things that I need to know to understand what’s happening.
“distinguish between changes and snapshots that have the same intent and content but which are completely non-interchangeable and imply entirely different flows of historical events” How do you even end up in a situation like that? Anyway, sounds like you should be able to merge them without conflicts, if they are in fact completely interchangeable?
“The natural mental model is that names denote global identity.” Why should another repo care, which names I use? How would you even synchronize naming across different repos without adding complexity, e.g. if two devs created a branch “experimental” or “playground”. Why on earth should they be treated as the same branch?
“Git uses the cached remote content, but that’s likely out of date” I actually agree that this can lead to some errors and confusion. But automation exists - you can just fetch every x minutes.
“Branches aren’t quite branches, they’re more like little bookmark go-karts.” A dev describing what basically is just a pointer in this way leads to the suspicion that it might not be Git’s mental model that is alien.
“My favorite version of this is when the novice has followed someone’s dodgy advice to set pull.rebase = true” Maybe don’t do stupid stuff you don’t understand? We know what fetch is, we know what merge is. Pull is basically fetch & merge.
““Pull” presents the illusion that you can just ask Git to make everything okay for you” Just… what? The rest of the sentence doesn’t really fix this error in expectations.
except the CLI of course, but I can use GUI-tools for most tasks
I also disagree with a lot of the reasoning. Like “If a commit has the same content but a different parent, it’s NOT the same commit” is not an “alien concept”. When I apply the same change to different parents, I end up with different versions. Which would be kinda bad for a Version Control System.
It’s also intuitive, it’s how frames in video compression work, too. And in fact if you have two kids that look virtually identical but are from different families, they are very clearly not the same person. Context matters, most people more-than-intuitively understand that.
“Git uses the cached remote content, but that’s likely out of date” I actually agree that this can lead to some errors and confusion. But automation exists - you can just fetch every x minutes.
Yeah and nevermind that virtually any tool does that for you. So this is a long-solved problem.
Yeah, you’re right, technically it’s not a “diff”, it’s the changed files.
I don’t think this technical detail has any consequences for the general mental model of Git though - as evidenced by the fact that I have been using Git for years without knowing this detail, and without any problems.
It’s all the files. Content-addreasable storage means that they might not take up any more space. Smart checkout means they might not require disk operations. But it’s the whole tree.
One problem, I think, is that git names are kinda bad. A git branch is just a pointer to a commit, it really doesn’t correspond to what we’d naturally think of as a branch in the context of a physical tree or even in a graph.
That’s a bit problematic for explaining git to programming newbies, because grokking pointers is famously one of the stumbling blocks people have, along with recursion. Front-end web developers who never learned C might not really grok pointers due to never really having to deal with them much.
Some other version control systems like mercurial have both a branch in a more intuitive sense (commits have a branch as a bit of metadata), as well as pointers to commits (mercurial, for example, calls them bookmarks).
As an aside, there’s a few version control systems like darcs where instead of the first-class concept being snapshots, it’s diffs. There’s no separate cherrypick command in darcs, it’s just one way you can use the regular commands.
A git branch is just a pointer to a commit, it really doesn’t correspond to what we’d naturally think of as a branch in the context of a physical tree or even in a graph.
But as the article points out, a commit includes all of its ancestors. Therefore pointing to a commit effectively is equivalent to a branch in the context of a tree.
Some other version control systems like mercurial have both a branch in a more intuitive sense (commits have a branch as a bit of metadata), as well as pointers to commits (mercurial, for example, calls them bookmarks).
I mean, git has bookmarks too, they’re called tags.
I disagree, hard.
I disagree with the general conclusion - I think it’s very easy to understand*: each repo has a graph of commits. Each commit includes the diff and metadata (like parent commits). There is a difference between you repo seeing the state of another repo (fetch) and copying commits from another repo into your repo (merge; pull is just a combination of fetch and pull). Tags are pointers to specific commits, branches are pointers to specific commits that get updated when you add a child commit to this commit. That’s a rather small set of very clear concepts for such a complex problem.
I also disagree with a lot of the reasoning. Like “If a commit has the same content but a different parent, it’s NOT the same commit” is not an “alien concept”. When I apply the same change to different parents, I end up with different versions. Which would be kinda bad for a Version Control System.
“This in turn means that you need to be comfortable and fluent in a branching many-worlds cosmology” - yes, if you need to handle different versions, you need to switch between them. That’s the complexity of what you’re doing, not the tool. And I like that Git is not trying to hide things that I need to know to understand what’s happening.
“distinguish between changes and snapshots that have the same intent and content but which are completely non-interchangeable and imply entirely different flows of historical events” How do you even end up in a situation like that? Anyway, sounds like you should be able to merge them without conflicts, if they are in fact completely interchangeable?
“The natural mental model is that names denote global identity.” Why should another repo care, which names I use? How would you even synchronize naming across different repos without adding complexity, e.g. if two devs created a branch “experimental” or “playground”. Why on earth should they be treated as the same branch?
“Git uses the cached remote content, but that’s likely out of date” I actually agree that this can lead to some errors and confusion. But automation exists - you can just fetch every x minutes.
“Branches aren’t quite branches, they’re more like little bookmark go-karts.” A dev describing what basically is just a pointer in this way leads to the suspicion that it might not be Git’s mental model that is alien.
“My favorite version of this is when the novice has followed someone’s dodgy advice to set pull.rebase = true” Maybe don’t do stupid stuff you don’t understand? We know what fetch is, we know what merge is. Pull is basically fetch & merge.
““Pull” presents the illusion that you can just ask Git to make everything okay for you” Just… what? The rest of the sentence doesn’t really fix this error in expectations.
It’s also intuitive, it’s how frames in video compression work, too. And in fact if you have two kids that look virtually identical but are from different families, they are very clearly not the same person. Context matters, most people more-than-intuitively understand that.
Yeah and nevermind that virtually any tool does that for you. So this is a long-solved problem.
I’d expect a developer to understand that. A stack trace works the exact same way.
Commits don’t store diffs, so you’re wrong from the start here.
Hence why people say “git is hard”
Yeah, you’re right, technically it’s not a “diff”, it’s the changed files.
I don’t think this technical detail has any consequences for the general mental model of Git though - as evidenced by the fact that I have been using Git for years without knowing this detail, and without any problems.
It’s all the files. Content-addreasable storage means that they might not take up any more space. Smart checkout means they might not require disk operations. But it’s the whole tree.
One problem, I think, is that git names are kinda bad. A git branch is just a pointer to a commit, it really doesn’t correspond to what we’d naturally think of as a branch in the context of a physical tree or even in a graph.
That’s a bit problematic for explaining git to programming newbies, because grokking pointers is famously one of the stumbling blocks people have, along with recursion. Front-end web developers who never learned C might not really grok pointers due to never really having to deal with them much.
Some other version control systems like mercurial have both a branch in a more intuitive sense (commits have a branch as a bit of metadata), as well as pointers to commits (mercurial, for example, calls them bookmarks).
As an aside, there’s a few version control systems like darcs where instead of the first-class concept being snapshots, it’s diffs. There’s no separate cherrypick command in darcs, it’s just one way you can use the regular commands.
But as the article points out, a commit includes all of its ancestors. Therefore pointing to a commit effectively is equivalent to a branch in the context of a tree.
I mean, git has bookmarks too, they’re called tags.
What happens after you merge a feature branch into main and delete it? What happens to the branch?
Afterwords, what git commands can you run to see what commits were made as part of the feature branch and which were previously on main?
Mercurial bookmarks correspond to git branches, while mercurial tags correspond to git tags.
It doesn’t. ☺