What's the convenient lie taught about branches?
The standard concept that I remember is 'a branch is a pointer to a commit', which still feels accurate
The standard concept that I remember is 'a branch is a pointer to a commit', which still feels accurate
People say things like "a branch does this" when they mean "We have rules on the git server that enforce this", or when they mean "We have a convention to do this, you have to keep track of it". One word to describe this is synecdoche - a part represents the whole or vice versa. Some part of the system does something, or some part of the PROCESS does something, and so people say "git does this thing".
Imprecise speech is shorter, but it can waste a great deal of time in the long run.
But yeah fixing up work and cleaning up a branch prior to merging is a feature not a bug. Git got it right.
A commit SHA represents the entire DAG up until that point, not a given changeset. So in your example, branch B is still a pointer to a commit, and branch A is a pointer to a different commit. Where is the convenient lie?
The method I had in mind is an interactive rebase. Assume there are n > 5 commits on my branch, choosing 5 arbitrarily. If I run “git rebase -i HEAD~5” then use the “drop” command on the third-most-recent commit, I do end up with a different DAG. The change is subtractive and not just the removal of the current HEAD.
This kind of history change is definitely a bit less common but not obscure by any means. I’ve rebased to drop commits on my own feature branches many times.
I would argue that is still not a convenient lie of "a branch is a pointer to a commit". Rather, the rebase command is changing what the branch is pointing to, and git tries to make that clear.
After that rebase command, there is a message like `Successfully rebased and updated refs/heads/yourbranch`, showing that the branch named yourbranch is now pointing at something new.
Your original comment:
>Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A.
My counterpoint taking this to the extreme:
>Consider the case where I create a new branch B from A then run git reset --hard SOMESHA1
In my example, again the new branch is pointing at a completely different commit--because I am repointing the branch.
Yes, git currently stores deltas between commits in its pack files, but that's an implementation detail to save space. Importantly, it's not how git was originally written, but was added at a later time (although, still a long time ago now).
Edit: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...