Jeff King <p...@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...
