Jeff King <peff@xxxxxxxx> writes: > When git-rev-list sees no pending commits, it shows a usage > message. This works even when reflog-walking is requested, > because the reflog-walk code currently puts the reflog tips > into the pending queue. > > In preparation for refactoring the reflog-walk code, let's > explicitly check whether we have any reflogs to walk. For > now this is a noop, but the existing reflog tests will make > sure that it kicks in after the refactoring. Likewise, we'll > add a test that "rev-list -g" without specifying any reflogs > continues to fail (so that we know our check does not kick > in too aggressively). > > Note that the implementation needs to go into its own > sub-function, as the walk code does not expose its innards > outside of reflog-walk.c. > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > This is actually the main "gotcha" I'm worried about with this series. > I'm not sure if any other code would care about seeing the pending items > in revs->commits. I still think the series is the right direction; if > there is such a place, we'd want to teach it to handle reflog walking in > a similar way, too. Ah, very good thinking---when I was following along your drafts to bypass the revs.commits queue for reflog walking, I didn't think of this one. Perhaps "!revs.commits && reflog_walk_empty(revs.reflog_info)" may want to become a macro "walk_finished(&revs)" or something to replace existing !revs.commits that is not accompanied by the check on .reflog_info field?
