Hi,
Jonathan Tan wrote:
> When a user checks out the upstream branch of HEAD and then runs "git
> branch", like this:
>
> git checkout @{u}
> git branch
>
> an error message is printed:
>
> fatal: HEAD does not point to a branch
Interesting. Even worse, it happens when I run "git status".
[...]
> This is because "git branch" attempts to DWIM "@{u}" when determining
> the "HEAD detached" message, but that doesn't work because HEAD no
> longer points to a branch.
>
> Therefore, when calculating the status of a worktree, only expand such a
> string, not DWIM it. Such strings would not match a ref, and "git
> branch" would report "HEAD detached at <hash>" instead.
[...]
> - if (dwim_ref(cb.buf.buf, cb.buf.len, &oid, &ref) == 1 &&
> + if (expand_ref(the_repository, cb.buf.buf, cb.buf.len, &oid, &ref) == 1 &&
> /* sha1 is a commit? match without further lookup */
Alas, as Junio mentions downthread, this patch produces a regression
in behavior: before,
$ git checkout --quiet master@{u}
$ git status | head -1
HEAD detached at origin/master
after,
$ git checkout --quiet master@{u}
$ git status | head -1
HEAD detached at 675a4aaf3b2
This ends up being a bit subtle.
The current branch can be in one of three states: I can be on a branch
(HEAD symref pointing to a ref refs/heads/branchname), detached (HEAD
psuedoref pointing to a commit), or on a branch yet to be born.
__git_ps1 in contrib/completion/git-prompt.sh, for example, is able to
show these three states.
Since b397ea4863a (status: show more info than "currently not on any
branch", 2013-03-13), "git status", on the other hand, gives richer
information. In the detached case, naming the commit that HEAD points
to doesn't really give a user enough information to orient themself,
so we look at the reflog (!) to find out what the user had intended to
check out. Reflog entries look like
checkout: moving from master to v1.0
and the "v1.0" can tell us that v1.0 is the tag that we detached HEAD
on.
This strikes me as always having been strange in a few ways:
On one hand, this is using the reflog. reflog entries are
historically meant to be human-readable. They are a raw string, not
structured data. They can be translated to a different human
language. Other tools interacting with git repositories are not
guaranteed to use the same string. Changes such as the introduction
of "git switch" could be expected to lead to writing "switch:" instead
of "checkout:" some day.
Beyond that, it involves guesswork. As b397ea4863a explains,
When it cannot figure out the original ref, it shows an
abbreviated SHA-1.
The reflog entry contains the parameter passed to "git checkout" in
the form the user provided --- it is not a full ref name or string
meant to be appended to refs/heads/ but it can be arbitrary syntax
supported by "git checkout". At the time that the checkout happened,
we know what *commit* that name resolved to, but we do not know what
ref it resolved to:
- refs in the search path can have been created or deleted since then
- with @{u} syntax, the named branch's upstream can have been
reconfigured
- and so on
If we want to know what ref HEAD was detached at, wouldn't we want
some reliable source of that information that records it at the time
it was known?
Another example is if I used "git checkout -" syntax. In that case,
the reflog records the commit id that I am checking out, instead of
recording "-". That's because (after "-" is replaced by "@{-1}") the
"magic branch" handler strbuf_branchname replaces @{-1} with with the
branch name being checked out. That branch name *also* comes from the
reflog, this time from the <old> side of the
checkout: moving from <old> to <new>
line, and <old> is populated as a simple commit id or branch name read
from HEAD. So this creates a bit of an inconsistency: if I run "git
status", "git checkout -", "git checkout -" again, and then "git
status" again, the first "git status" tells me what ref I had used to
detach HEAD but the second does not.
Okay, so much for background.
The motivating error producing
fatal: HEAD does not point to a branch
is a special case of the "we do not know what ref it resolved to"
problem described above: the string @{upstream} represents the
upstream of the branch that HEAD pointed to *at the time of the
checkout*, but since then HEAD has been detached.
[...]
> One alternative is to plumb down a flag from dwim_ref() to
> interpret_branch_mark() that indicates that (1) don't read HEAD when
> processing, and (2) when encountering a ref of the form "<optional
> ref>@{u}", don't die when the optional ref doesn't exist, is not a
> branch, or does not have an upstream.
Given the context above, two possibilities seem appealing:
A. Like you're hinting, could dwim_ref get a variant that returns -1
instead of die()ing on failure? That way, we could fulfill the
intent described in b397ea48:
When it cannot figure out the original ref, it shows an abbreviated
SHA-1.
B. Alternatively, in the @{u} case could we switch together the <old>
and <new> pieces of the context from the
checkout: moving from master to @{upstream}
reflog line to make "master@{upstream}"? It's still possible for
the upstream to have changed since then, but at least in the
common case this would match the lookup that happened at checkout
time.
Thoughts?
Thanks,
Jonathan
