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!
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.