I think this post makes an unnecessary distinction and unnecessarily leaves their connection open, making it more complex.
The baseline and reasoning should always be the HEAD, represented by .git/HEAD. Describing what they call a “revision parameter” or output should always refer to and be defined by that baseline. Because that’s what it uses and refers to.
Instead of “closely related” we can say one refers to the other. The context on “ways git uses HEAD in its output” implies/seems to nudge to me that it’s something different; but again, a HEAD label references HEAD. There’s no variance in what HEAD refers to.
<span style="color:#323232;">HEAD -> sha1 (commit) => detached head (not on any branch)
</span><span style="color:#323232;">HEAD -> refs/heads/branchname -> sha1 (commit) => on branch branchname
</span>
All of these things (HEAD, HEAD^^^, HEAD@[2}) are called “revision parameters”. They’re documented in man gitrevisions, and Git will try to resolve them to a commit ID.
While they listed a commit range in the example, they fail to mention it here. A revision range does not resolve to only one commit. (“Specifying ranges” is documented on the same git man page.)
For example, git talks about “detached HEAD state”, but never about “attached HEAD state” – git’s documentation never uses the term “attached” at all to refer to HEAD. And git talks about being “on” a branch, but never “not on” a branch.
I think it’s a good choice to not unnecessarily complicate default mode and usage. Detached HEAD is the exceptional state, and not commonly used.
So it’s very hard to guess that on branch main is actually the opposite of HEAD detached. How is the user supposed to guess that HEAD detached has anything to do with branches at all, or that “on branch main” has anything to do with HEAD?
I can agree it’s not obvious though. It requires understanding of what HEAD actually is - which is useful for the other things you list too (specifying revisions and understanding output).
I’m not sure if there’s a good or better way for introducing the user to it though. It’s inherent tool complexity. And I don’t think calling every HEAD attached when it points to a branch is verbose to the point of being detrimental.
I don’t find the HEAD in diffs between merge and rebase confusing. When I rebase commits I am always aware of the replay activity. (I mainly use TortoiseGit where it is always obvious through updating rebase progress.)
Displaying the original HEAD before the rebase started would be wrong and even more confusing. Because that HEAD and commit is no longer part of any of the changes. You are on a different base, and you are cherry picking onto it.
I thought HEAD was just a ref that points to the commit in history where you are right now. Like a “you are here” label. That’s it.
Detached HEAD meaning that the HEAD ref doesn’t point to the same commit as the branch ref that always follows the last commit in a development branch.
Detached HEAD meaning that the HEAD ref doesn’t point to the same commit as the branch ref that always follows the last commit in a development branch
IMO this is misleading, or incomplete.
HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.
When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.
From a use case perspective that may illustrate the difference:
When HEAD points to a branch, and I commit, I commit to that branch.
When HEAD points to a commit ([branch] detached HEAD), and I commit, I create a commit, and HEAD points to the new commit, but there is no branch pointing to it. (A followup is needed, e.g. creating a branch, or updating an existing branch, to keep the new commit discoverable even after we change what HEAD points to - e.g. by switching to a branch.)
I thought HEAD was just a ref
“refs” are stored in .git/refs/heads - but HEAD is not. In that sense, HEAD is not a ref like the others (branches and tags and whatever else you put there, like pull request references).
HEAD is either a reference or a reference to a reference. Branches are references.
HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.
That’s what I was saying.
When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.
You can still be in detached HEAD state and still be in a branch in a sense that your working tree reflects a commit that’s in a series of commit that follow a certain bifurcation. If that makes any sense.
But as soon as you make changes and commit, you create a “branch within a branch” though that “branch” doesn’t have a branch ref pointing to it.
Add comment