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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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...