Junio C Hamano <gitster@xxxxxxxxx> writes:
> OK. "Detached at <hash>" is somewhat unsatisfactory (you most
> likely have detached from refs/remotes/origin/<something>), but
> it is much better than "fatal" X-<.
>
>> 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. (We cannot change the
>> functionality outright because other parts of Git rely on such a message
>> being printed.)
>
> Thanks for a good analysis. That likely is a good direction for a
> longer term. @{upstream} is "tell me the upstream of the branch
> that is currently checked out", right? So it is reasonable to
> expect that it has no good answer in a detached HEAD state. And
> when on a branch, that branch may not have an upstream, and we
> should prepare for such a case, too.
Well, I have to take this back.
The real cause of the problem is that we record in reflog that we
switched to @{u}, but when get_detached_from() tries to "dwim" it,
the "current branch" that is implicitly there to be applied to @{u}
is different one from what used to compute which branch to check
out, isn't it? And it probably is not limited to @{upstream} but
other @{<stuff>} that implicitly apply to the "current branch",
e.g. @{push}.
This causes a few potential problems:
- The "current" branch may be different from the one when such a
reflog entry that refers to @{<stuff>} when we later yank
@{<stuff>} out of the reflog and try to use it. This is the
problem the patch under discussion tries to hide, but the patch
also breaks cases that are working fine.
- Even if the user gave the branch name (i.e. 'next@{upstream}' in
the example this patch would have introduced a regression) or if
we updated get_detached_from() to correctly infer the branch that
was current when the reflog entry in which we found @{upstream}
was recorded, the upstream for the branch may have been
reconfigured between the time when the reflog entry was written
and get_detached_from() is called. 'next@{upstream}' may have
been 'origin/next' back then but it may be a different
remote-tracking branch now. This issue is not solved by the
patch---the issue is unfixable unless we log the changes to the
branch configuration so that we can figure out what was the
upstream of 'next' back then, which we won't do.
Assuming that is the root cause, I think the right solution likely
lies along these three lines:
(1) record not @{<stuff>} (or <branch>@{<stuff>} for that matter),
but the actual starting point in the reflog (e.g. in the
example this patch would have introduced a regression,
i.e. next@{u}, we should record 'origin/next'. In the example
this patch would have used degraded output to prevent dying,
i.e. @{u}, we should also record 'origin/next')---this also
will fix the "the branch's upstream may be different now"
problem.
(2) a patch like yours to use expand_ref() as a fallback, but only
for the "@{<stuff>}" notation that depends on what the "then
current" branch was---this is a mere band-aid, like the patch
under discussion is, but at least it would not regress the
cases that are "working". "The upstream may be different now"
problem is still there.
(3) when we have to interpret @{<stuff>} found in the reflog, go
back to see which branch was current, and compute @{<stuff>}
relative to that branch---this would "fix" more cases than (2)
would, but it won't fix "the upstream can change" problem, and
I think the trade-off is not all that great.
I think the combination of (1) and (2) is likely to be the best way
to go. (1) will remove the root cause, and (2) will allow us to
cope with reflog entries before (1) is applied.
