4 ms·

I'm still missing what part of the intuition is incorrect? It seems like the only "incorrectness" is that there's no explicit hierarchy of branches. Except that

I'm still missing what part of the intuition is incorrect? It seems like the only "incorrectness" is that there's no explicit hierarchy of branches. Except that's wrong the HEAD ref points to the default branch. Any other branches are of equal significance, though.

mgerdts 3y ago
Intuition would be that the branch starts at the point that it diverges from main, labeled “base” in the first diagram. In reality, the first commit in “main” and “branch” are the same commit. Intuition likely comes from how a tree (fir or oak, not binary) is structured. Generally a branch starts at the trunk or some other branch, not at the ground where the trunk gives way to roots.
- jancsika 3y ago
  I don't agree with the author here. Intuition is travelling down main path that has branches which diverge and re-merge into the main path. That's why people seem to intuitively get "merging" back into main, whereas that doesn't generally make sense for physical trees.
Sharlin 3y ago
No, the HEAD ref points to whatever branch is "active", that's how the active branch is defined. Indeed `git checkout branchname` does nothing except make HEAD point to the commit that `refs/heads/branchname` points to. The intuition jvns meant is the idea that a branch only constitutes the commits since the point of divergence, but every branch actually contains the full history up to the root of its tree, and `git log` of course shows that. (If you want to only show the commits specific to a branch, you can do `git log parent..branch`. Note also that two branches need not have any common history, it's perfectly possible for a git graph to be disconnected.)
- xorcist 3y ago
  > `git checkout branchname` does nothing except make HEAD point to the commit You probably know this, but since we are being pedantic we might as well get it right: That describes "git reset". "git checkout" does that and record that we are tracking branchname. So any commits will move both HEAD and the branchname reference.
  - Izkata 3y ago
    Well along those same lines, making a commit doesn't move HEAD, it's still pointing at the same branchname as before. cat .git/HEAD
zestyping 3y ago
The intuition is that a branch consists of a line of commits off of a trunk. Like, you know, what the word "branch" means in real life. But in git, a branch doesn't "contain" anything. It is just a pointer to a single commit. This is completely counterintuitive and makes no sense to most people at first, for a very good reason: the analogy is misleading. These things shouldn't be called branches. They are pointers: they can be repointed anywhere, dereferenced, and copied by reference. HEAD is also a stupid term, because it doesn't refer to the head of anything. HEAD is the current pointer, and it can point to any commit, not just the head of a branch. It should be called something like "here". The "detached HEAD" warning is scary and useless. Just look at these two commands, which do very similar things but look totally different: git checkout -b staging git branch -f staging 3d1b582 They are just pointer assignments. Wouldn't it make a lot more sense if they were written like this? git point staging here git repoint staging 3d1b582

mgerdts 3y ago

Intuition would be that the branch starts at the point that it diverges from main, labeled “base” in the first diagram. In reality, the first commit in “main” and “branch” are the same commit. Intuition likely comes from how a tree (fir or oak, not binary) is structured. Generally a branch starts at the trunk or some other branch, not at the ground where the trunk gives way to roots.

jancsika 3y ago
I don't agree with the author here. Intuition is travelling down main path that has branches which diverge and re-merge into the main path. That's why people seem to intuitively get "merging" back into main, whereas that doesn't generally make sense for physical trees.

Sharlin 3y ago

No, the HEAD ref points to whatever branch is "active", that's how the active branch is defined. Indeed `git checkout branchname` does nothing except make HEAD point to the commit that `refs/heads/branchname` points to. The intuition jvns meant is the idea that a branch only constitutes the commits since the point of divergence, but every branch actually contains the full history up to the root of its tree, and `git log` of course shows that. (If you want to only show the commits specific to a branch, you can do `git log parent..branch`. Note also that two branches need not have any common history, it's perfectly possible for a git graph to be disconnected.)

xorcist 3y ago
> `git checkout branchname` does nothing except make HEAD point to the commit You probably know this, but since we are being pedantic we might as well get it right: That describes "git reset". "git checkout" does that and record that we are tracking branchname. So any commits will move both HEAD and the branchname reference.
- Izkata 3y ago
  Well along those same lines, making a commit doesn't move HEAD, it's still pointing at the same branchname as before. cat .git/HEAD

zestyping 3y ago

The intuition is that a branch consists of a line of commits off of a trunk. Like, you know, what the word "branch" means in real life. But in git, a branch doesn't "contain" anything. It is just a pointer to a single commit. This is completely counterintuitive and makes no sense to most people at first, for a very good reason: the analogy is misleading. These things shouldn't be called branches. They are pointers: they can be repointed anywhere, dereferenced, and copied by reference. HEAD is also a stupid term, because it doesn't refer to the head of anything. HEAD is the current pointer, and it can point to any commit, not just the head of a branch. It should be called something like "here". The "detached HEAD" warning is scary and useless. Just look at these two commands, which do very similar things but look totally different: git checkout -b staging git branch -f staging 3d1b582 They are just pointer assignments. Wouldn't it make a lot more sense if they were written like this? git point staging here git repoint staging 3d1b582