On Thu, Jul 06, 2017 at 08:42:45AM -0700, Junio C Hamano wrote:
> >> 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.
>
> Yes, I agree that sequential is easy to explain, but only when I
> consider use of "log" family without "-n 30" or "--since 3.days".
> It still is easy to explain---we show from one and then from the
> other, but because we stop after showing 30 of them, and the first
> one has more than that, you do not see any from the latter.
Ah, right, I didn't think of limiting like that. I agree that makes a
strong argument in favor of the date-ordered queue.
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.
-Peff
