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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2017, 06:00 UTC
Message-ID: <xmqq37a8eqhe.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170707051954.rpej3taew6onv3oo@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> I suspect that "--since 3.days" is still quite buggy (even with a single
> reflog) because it checks commit timestamps and stops traversing when we
> go too bar back. But in a reflog, the commits may be totally out of
> order. I'm not sure what it should do. Either:
>
>   1. During a reflog walk, --since and --until should respect reflog
>      timestamps instead of commit timestamps. You can already do
>      "--until" there by simply starting the traversal later, but there's
>      no way to cut it off with --since.
>
>   2. Limit commits shown by --since/--until as usual, but skip the "stop
>      traversing" optimization when we see too many "old" commits. I.e.,
>      omit a 4.days.ago commit, but keep walking to find other recent
>      commits.

I think 1. is more logical, and I was imagining that it should be doable, now we are not constrained by (ab)using the commit_list with the fake-parent thing, but are pulling the entries directly from the reflog iterator and the timestamp would be already available to the iterator.

But I recall that the max_age and min_age cutoff is done long after a commit is pulled out of the "iterator mechanism" (be it the commit_list or your direct reflog iterator) by comparing commit->date with the cut-off, so it may be a bit more involved to arrange than I imagined X-<. Hmph...