Twenty years is nothing, but twenty years in computer history, considering computer science as an academic discipline is barely 80 years old, is a quarter of it. Much, much less if you’re only talking about personal computing, and even worse if only focusing on software engineering as a field.
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.
HEAD -> sha1 (commit) => detached head (not on any branch)
HEAD -> refs/heads/branchname -> sha1 (commit) => on branch branchname
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.
You never reach a phase when you can confidently say that you understand git. But it's certainly possible to go from "When something goes wrong, I just delete the repo and clone it again" to "Aha! Now I can deal with most of the issues".
Mine was when I realized that git commands come in two flavors. Those that deal with commits as snapshots (commit, checkout, switch, reset, etc) and those that deal with commits as changes/diffs/deltas (merge, rebase, cherrypick, revert, etc). (Note: This isn't about how git stores commits on disk). I believe that this is actually the main source of confusion for beginner and intermediate git users.
Still haven't. And I really dislike articles that say stuff like "git doesn't really store diffs!" followed by a bunch of paragraphs showing they don't understand what git does store or they are bad at explaining things (or both).
When I learned about the reflog. I became less afraid of my changes when I knew I could easily recover from my errors. This allowed me to experiment more with git and become more proficient in it.
Another aha moment was learning that an easy way to squash commits is just to do a git reset followed by git commit -am “whatever”
Every commit lists one or more parents, possibly several parents, like 8 parents. These commits thus form a graph structure.
Branches and labels are just references to commits in this graph structure; they are commit alias, just a name that references a specific commit. Branches and tags are the same, except by convention the CLI will move branches when you commit to a branch, but tags are not moved by the CLI.
(Commits may have many names, they have their commit ID, and they may also be named by a branch or tag. Commit IDs are hashes of the contents of the commit. This ensures, cryptographically, that a commit and it's ID can never change.)
Git never deletes a commit that is less than 90 days old. If you commit something, rest assured your work is in there somewhere, it's just that no mortal being may be able to find it. Deleting a branch removes a reference to a commit, but the commits in the branch are still there. The GUI tools usually hide commits that are not part of a branch, but you can see them using "reflog" related commands.
Fun fact. Such merges with more than 2 parents are called 'octopus merges'. The Linux repo has a single merge with 66 parents that Torvalds named the 'Cthulhu merge'.
Git never deletes a commit that is less than 90 days old.
On its own, that is. Not if you do a git gc.
Deleting a branch removes a reference to a commit, but the commits in the branch are still there.
but you can see them using “reflog” related commands
Reflog - one of the most underrated git commands that has the potential to save your life some day. At least one team member must learn it.
I discovered it, along with other DVCS when it came up, and looked into it and learned it. It was reasonable and intuitive enough for me. As far as I can remember anyway. (I don't have particular memories of that.)
That time I accidentally wiped an entire open source project on github and had to learn real quick how to undo a destructive commit.
Somehow after an entire night of google-fu, reading the git book three times, and tutorial videos, I got the right series of commands to fix it and nobody ever figured out what I did.
All I wanted to do was fix a typo in an imported module...
Git
Newest