4 ms·

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

chungy 3y ago
Given TFA (a comic) has "you might expect git to enforce some rules about branches", I figured there might be an education problem going on. I didn't expect such things, but being there from the earliest days might be why. I don't even think reset and rebase are "weird stuff", for that matter. I use them multiple times a week.
DiggyJohnson 3y ago
I’m not GP, but the main one I see if the mental model that a commit is a full representation of the contents of the repo at the time that commit was created (rather than being a change set or deltas between commits).
- Brian_K_White 3y ago
  Right in this subthread people have said that. I now have no idea what is right. Which seems to only support the comics assertion, which was only "you might think x but you'd be wrong"
  - weaksauce 3y ago
    originally every commit was a full snapshot of the current state of the repository. the repository is now compressed after the fact using deltas but like another person said but it’s really just an implementation detail.
- Karellen 3y ago
  Um, I'm pretty sure that one's not a lie. 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%3F https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...
dcow 3y ago
The way I'm reading the comic, it'd be something like "main/master is special", and "always merge in changes". Things that make people assume that forward history is somehow enforced by the software. But yeah fixing up work and cleaning up a branch prior to merging is a feature not a bug. Git got it right.
csours 3y ago
Other people did not get the education you got. Thus, this being a problem with education. 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.
nophunphil 3y ago
It's accurate in most common workflows, but definitely a convenient lie. 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.
- yankjenets 3y ago
  By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1? 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?
  - nophunphil 3y ago
    That is one way to “remove a commit” and I agree with your analysis for that case. 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.
    - yankjenets 3y ago
      Ah ok, understood. 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.

chungy 3y ago

Given TFA (a comic) has "you might expect git to enforce some rules about branches", I figured there might be an education problem going on. I didn't expect such things, but being there from the earliest days might be why. I don't even think reset and rebase are "weird stuff", for that matter. I use them multiple times a week.

DiggyJohnson 3y ago

I’m not GP, but the main one I see if the mental model that a commit is a full representation of the contents of the repo at the time that commit was created (rather than being a change set or deltas between commits).

Brian_K_White 3y ago
Right in this subthread people have said that. I now have no idea what is right. Which seems to only support the comics assertion, which was only "you might think x but you'd be wrong"
- weaksauce 3y ago
  originally every commit was a full snapshot of the current state of the repository. the repository is now compressed after the fact using deltas but like another person said but it’s really just an implementation detail.
Karellen 3y ago
Um, I'm pretty sure that one's not a lie. 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%3F https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...

dcow 3y ago

The way I'm reading the comic, it'd be something like "main/master is special", and "always merge in changes". Things that make people assume that forward history is somehow enforced by the software. But yeah fixing up work and cleaning up a branch prior to merging is a feature not a bug. Git got it right.

csours 3y ago

Other people did not get the education you got. Thus, this being a problem with education. 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.

nophunphil 3y ago

It's accurate in most common workflows, but definitely a convenient lie. 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.

yankjenets 3y ago
By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1? 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?
- nophunphil 3y ago
  That is one way to “remove a commit” and I agree with your analysis for that case. 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.
  - yankjenets 3y ago
    Ah ok, understood. 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.