> I think HEAD would be more intuitive if git’s terminology around HEAD were a little more internally consistent.
HEAD is whatever commit is currently checked out, full stop.
When resolving conflicts during a rebase that HEAD will be the commit that the one being cherry-picked is being picked onto. To understand this it's useful to just know that rebase is just a script of cherry-picks.
> [...] I don’t think you can do it with a regular git command. I’d be interested to know if there is a regular-git-command way to make .git/HEAD a non-branch reference though, and if so why you might want to do that!
various git checkout commands can get you there, e.g. `git checkout FETCH_HEAD` after fetching something like refs like refs/pull/x/head (github) or equivalent to-review thing (gerrit has refs/changes/x/y/z, gitlab refs/merge-requests/x/head)
I'm reviewing stuff all the time and never bother with branches much (I create a branch before moving off if required, or directly on the remote by pushing the current detached head with a name); and it annoys me to no end when tools like b4 want HEAD to be a branch and just don't work until I create one for the current commit. Thankfully ths has gotten pretty rare.
Alternatively you can explicitly get there through `git checkout --detach <branch>` but I'm not aware of much use case for this one.
I think Julia is talking about the literal contents of .git/HEAD. If you run `git checkout FETCH_HEAD`, you'll checkout the same commit ID that's in FETCH_HEAD, but the contents of .git/HEAD will be that commit ID. It won't literally be the string "FETCH_HEAD".
I'm pretty sure Julia is correct. The contents of HEAD are always either a commit ID or the name of a local branch ref. That's what she means by it not containing a non-branch reference. i.e. it will never be the literal string "ref: refs/tags/..." or "ref: refs/remotes/origin/...". It will always be either "ref: refs/heads/..." or a commit ID.
thanks; I indeed read though the first part too fast... "HEAD is either a reference or a commit id. the reference must be a branch if using git commands" indeed allows git commands to make detached heads (that surprised me a bit given she pointed at git branchless...)
I'm indeed not aware of any command that's store a tag in there, ignore me!
I've heard git described not as a version-control program, but as a toolkit for making a version-control program.
Which makes sense--it explains why sometimes there's no obvious "right" way to do things, and why there are spots where either there is no abstraction or it's pretty leaky in terms of implementation details.
I felt I fully understood git after I realized it was just a data structure.
The data structure isn't even complicated (there are commits, and then there are directories and files associated with the commits), and once I understood the tooling (i.e. git commands) in terms of how it manipulated the data structures, I was basically able to do whatever I intended to on the repo.
This adds confusion because it is not literally a symlink and it doesn't always act like a symlink either. It also assumes people understand the difference between a symbolic link and a hard link.
HEAD is a pointer. It points either indirectly to a commit through the name of a branch, or directly to a commit when you've checked out something other than a local branch (so called detached HEAD). In this way it acts both like a symlink and like a hard link. So:
HEAD -> branch name -> commit ID; or
HEAD -> commit ID.
Its literal representation is a file named HEAD whose contents are either the name of a branch or a commit ID.
A tag is also a pointer. It may also point either indirectly to a commit through an annotated tag object or directly to a commit (so called lightweight tag). So:
tag -> tag object -> commit ID; or
tag -> commit ID.
Its literal representation is
a file under refs/tags named after the tag and whose contents are the ID of the tag or commit object.
(Ignoring optimizations such as packed refs and the exact formatting of ref files. See Git book and man pages for details, or poke around your local .git directory. It's very explorable.)
This section in particular piques my interest. I never found this confusing, since the change in HEAD is just representative of the order of operations (in rebase, you are setting the current commits "on top" of the commit you are rebasing onto, etc). This feels like what is confusing isn't really HEAD itself, it's a fundamental understanding of the git model?
I feel like folks using git without understanding the basics of what it does is what leads people astray? If so, why isn't this part of our basic training as engineers who use git?
HEAD is whatever commit is currently checked out, full stop.
When resolving conflicts during a rebase that HEAD will be the commit that the one being cherry-picked is being picked onto. To understand this it's useful to just know that rebase is just a script of cherry-picks.