3 ms·

For me the parts that break my mental model are stuff like trying to check out an historical revision and ending up with a scary warning about a detached HEAD (

by kibibu 3y ago

For me the parts that break my mental model are stuff like trying to check out an historical revision and ending up with a scary warning about a detached HEAD (wtf), or not being able to easily start a new branch from an older commit (like you could very easily in mercurial).

nerdponx 3y ago
> detached HEAD Believe it or not this actually fits into the model, albeit with a little more complexity. HEAD is a special label that can point to other labels, specifically to "heads" which are the labels that represent branch tips. Normally when you make a new commit, the current pointed-to branch head advances forward to point to the new commit, and the HEAD pointer follows that branch head pointer. "Detached HEAD" is whenever HEAD points directly to a commit rather than a branch head. When making new commits in this state, there's no branch head to advance, so HEAD itself will advance to the newly-created commit. However this is a little dangerous because once you switch HEAD to something else, commits in the DAG without a branch head at the tip/leaf would be considered "unreachable" and would be invisible in logs, and eventually will be deleted by the garbage collection process. It's still ultimately all about operations on the commit DAG and labels/pointers therein, which to me is really elegant. What is not necessarily clear from that mental model is what any given operation will actually do to the files in your repo (called the "work tree"). But Git is very consistent here and usually tries to keep the work tree in sync with whatever is ultimately pointed to by HEAD, unless you specifically ask it not to (as with `reset --soft`). > not being able to easily start a new branch from an older commit Unfortunately this is a case of CLI docs obfuscation: git branch new-branch old-commit
- avgcorrection 3y ago
  They should have just called detached HEAD for branchless mode. That's all that it is: HEAD is directly on a commit instead of pointing to a branch. Clearer and less caps lock. But people also complain about the “branch” term so maybe they would like the more internal “head” term? In which case we're back to square one.
  - nerdponx 3y ago
    I suspect that the name "detached HEAD" is just a pun. Cute if you already know what all this stuff means, confusing otherwise.
    - avgcorrection 3y ago
      Inside joke for a handful of people which confuses thousands of people would truly be in the tradition of open source.
  - kibibu 3y ago
    I think I found it extra confusing because this action (check out previous commit, do some work, merge with main) was completely supported in my previous dvcs of choice, Mercurial.
    - deleted 3y ago
      [deleted]
    - nerdponx 3y ago
      The Git idiom in general is to make a branch for any work you intend to keep. But I'm also curious what you mean by doing work on a previous commit and then merging with main. Maybe it's a way to solve a problem I hadn't considered before.
      - kibibu 3y ago
        Been a long time since I used Hg, and I've mostly trained myself out of these ideas, but I'll try to recall the use cases. 1. Consider doing a bisect to find when a bug was introduced (which may now be in multiple branches) and being able to fix it immediately then merge and/or rebase over the current versions. 2. Working on a branch, you realize that you'd like to try an alternative approach to a problem. You check out a previous commit, leaving the branch in its non-working state, and try your alternative approach. If it works, you keep going on this version, otherwise you can just switch back. The temporary unnamed branch continues to exist until you choose to delete it (ideally before pushing!) . This unlocks a much lower inertia way to do small experimental work without having to formally label new branches, which carries enough weight to make me hesitate. I would do this all the time in Hg and almost never in git. In git I would probably reach for stash to achieve something similar.

by kibibu 3y ago

nerdponx 3y ago

> detached HEAD Believe it or not this actually fits into the model, albeit with a little more complexity. HEAD is a special label that can point to other labels, specifically to "heads" which are the labels that represent branch tips. Normally when you make a new commit, the current pointed-to branch head advances forward to point to the new commit, and the HEAD pointer follows that branch head pointer. "Detached HEAD" is whenever HEAD points directly to a commit rather than a branch head. When making new commits in this state, there's no branch head to advance, so HEAD itself will advance to the newly-created commit. However this is a little dangerous because once you switch HEAD to something else, commits in the DAG without a branch head at the tip/leaf would be considered "unreachable" and would be invisible in logs, and eventually will be deleted by the garbage collection process. It's still ultimately all about operations on the commit DAG and labels/pointers therein, which to me is really elegant. What is not necessarily clear from that mental model is what any given operation will actually do to the files in your repo (called the "work tree"). But Git is very consistent here and usually tries to keep the work tree in sync with whatever is ultimately pointed to by HEAD, unless you specifically ask it not to (as with `reset --soft`). > not being able to easily start a new branch from an older commit Unfortunately this is a case of CLI docs obfuscation: git branch new-branch old-commit

avgcorrection 3y ago
They should have just called detached HEAD for branchless mode. That's all that it is: HEAD is directly on a commit instead of pointing to a branch. Clearer and less caps lock. But people also complain about the “branch” term so maybe they would like the more internal “head” term? In which case we're back to square one.
- nerdponx 3y ago
  I suspect that the name "detached HEAD" is just a pun. Cute if you already know what all this stuff means, confusing otherwise.
  - avgcorrection 3y ago
    Inside joke for a handful of people which confuses thousands of people would truly be in the tradition of open source.
- kibibu 3y ago
  I think I found it extra confusing because this action (check out previous commit, do some work, merge with main) was completely supported in my previous dvcs of choice, Mercurial.
  - deleted 3y ago
    [deleted]
  - nerdponx 3y ago
    The Git idiom in general is to make a branch for any work you intend to keep. But I'm also curious what you mean by doing work on a previous commit and then merging with main. Maybe it's a way to solve a problem I hadn't considered before.
    - kibibu 3y ago
      Been a long time since I used Hg, and I've mostly trained myself out of these ideas, but I'll try to recall the use cases. 1. Consider doing a bisect to find when a bug was introduced (which may now be in multiple branches) and being able to fix it immediately then merge and/or rebase over the current versions. 2. Working on a branch, you realize that you'd like to try an alternative approach to a problem. You check out a previous commit, leaving the branch in its non-working state, and try your alternative approach. If it works, you keep going on this version, otherwise you can just switch back. The temporary unnamed branch continues to exist until you choose to delete it (ideally before pushing!) . This unlocks a much lower inertia way to do small experimental work without having to formally label new branches, which carries enough weight to make me hesitate. I would do this all the time in Hg and almost never in git. In git I would probably reach for stash to achieve something similar.