> (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.
This sounds reasonable. I took a look at this.
The part that converts the user-given refname (e.g. "@{u}") into an OID
is the invocation of get_oid_mb() in parse_branchname_arg() in
builtin/checkout.c, and get_oid_mb() eventually calls repo_dwim_ref()
which has access to the absolute branch name ("origin/master"). I did
not try plumbing it all the way, but I tried overriding "arg" with
"refs/remotes/origin/master" after the call to get_oid_mb() and it
worked.
For reference, the stack between get_oid_mb() and repo_dwim_ref() is as
follows (the line numbers may not be accurate because of some debug
statements I added):
repo_dwim_ref (refs.c:597)
get_oid_basic (sha1-name.c:875)
get_oid_1 (sha1-name.c:1195)
get_oid_with_context_1 (sha1-name.c:1812)
get_oid_with_context (sha1-name.c:1959)
repo_get_oid (sha1-name.c:1610)
repo_get_oid_mb (sha1-name.c:1382)
Besides the increase in complicatedness of all the listed functions that
we would need in order to plumb the absolute branch name through, I
haven't checked if the absolute branch name is the one that we should
use whenever we write to the reflog, or if there are some times that we
still want to use the user-specified name. I'll take a further look, but
any ideas are welcome.
