Re: [PATCH 2/6] t1414: document some reflog-walk oddities

From: Jeff King <peff@peff.net>
Date: Jul 6, 2017, 07:16 UTC
Message-ID: <20170706071606.doxirwm6cqx3duzg@sigill.intra.peff.net>
In-Reply-To: <xmqqa84ih5ao.fsf@gitster.mtv.corp.google.com>

On Wed, Jul 05, 2017 at 03:45:03PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> > I did make the ordering intentional. We process each reflog sequentially
> > in turn. I don't think it would be wrong to interleave them by date, but
> > I actually think it's useful for somebody who switches that behavior to
> > consciously update the test. Maybe it's worth calling out in the commit
> > message.
> >
> > I stopped short of actually documenting and guaranteeing that behavior
> > to the user. I don't know how comfortable we would be changing it later.
> 
> I somehow feel that the "showing all entries from HEAD and then
> showing all from side" is simply a buggy behaviour.  I do not think
> our users would terribly mind if we changed it later.  But I may be
> missing the reason why (sometimes?) the sequential behaviour may be
> useful.

If we think it's buggy, we can fix it now. But I'm not convinced that sequential iteration is that bad. It's at least _simple_ and easy to explain. The only other thing that would make sense to me is sorting the entries by date (reflog date, not commit date) and showing them in that order. But that gives rise to some funny corner cases.

What do we do if there's clock skew within the reflog (e.g., somebody fixed their skewed clock such that HEAD@{5} is less recent than HEAD@{6}). Do we show them out of order then (even if only a single reflog is being shown?).

Or do we try some complicated sort where entries compare sequentially within a given reflog, but use date comparisons between different logs? I don't think that can work with a normal comparison sort, as it makes the comparison non-transitive.

But maybe we could do a pseudo-list-merge, where we treat the reflogs as queues and always pick from the queue with the most recent timestamp.

That would probably be pretty easy to retrofit on the iteration from the current series.

-Peff