Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> 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.
Ah, blast from the past. Thanks for resurrecting.
If we are allowed to change what goes to reflog, can we do even
better than recording master@{upstream} at the time "checkout"
records the HEAD movement? "checkout: moving from next to master"
would be far better than "moving from next to next@{upstream}" or
"moving from next to @{upstream}".
Can we even change the phrasing altogether, like "checkout: moving
from next to detached e9b77c..."? That would produce even more
precise report.
