On Fri, Jul 07, 2017 at 11:54:05AM -0400, Kyle Meyer wrote:
> Jeff King <[email protected]> writes:
>
> > Prior to this commit, we show both entries with
> > identical reflog messages. After this commit, we show
> > only the "comes back" entry. See the update in t3200
> > which demonstrates this.
> >
> > Arguably either is fine, as the whole double-entry
> > thing is a bit hacky in the first place. And until a
> > recent fix, we truncated the traversal in such a case
> > anyway, which was _definitely_ wrong.
>
> Yeah, I agree that the double-entry thing is a bit hacky and only
> showing the "comes back" entry makes sense.
>
> And with this change, I believe that the display of a rename event will
> be the same for HEAD's log and the renamed branch's log, despite the
> underlying entries having a different representation.
There's one minor difference: the numbering for HEAD will show a "hole"
in the reflog. So on the branch you might see something like:
$ git log -g --oneline other
269000b other@{0}: Branch: renamed refs/heads/master to refs/heads/other
269000b other@{1}: commit (initial): foo
but the HEAD reflog will show:
$ git log -g --oneline HEAD
269000b HEAD@{0}: Branch: renamed refs/heads/master to refs/heads/other
269000b HEAD@{2}: commit (initial): foo
This is pretty minor. I do wonder if there are other bits that might be
confused, though. Looking at the hole is odd:
$ git show --oneline HEAD@{1}
warning: Log for ref HEAD unexpectedly ended on Sun, 9 Jul 2017 06:07:05
-0400.
269000b foo
Despite the warning, we do seem to correctly walk past it, though:
$ git show --oneline HEAD@{2}
269000b foo
-Peff