Jeff King <peff@xxxxxxxx> writes: >> Yeah. You could imagine that `rev-list --count` might do something >> fancy like coalescing >> >> git rev-list --count B...C1 B...C2 B...C3 >> >> into a single walk. But I am not sure that just because `rev-list >> --count` provides similar functionality that we should fold in the >> proposed `ahead-behind` interface into that flag. > > It does coalesce all of that into a single walk. The problem is somewhat > the opposite: it only has a notion of two "sides" for a symmetric > traversal: left and right. But in your example there are many sides, and > we have to remember which is which. Yeah, this reminds me of what I had to do in "show-branch", where each tip gets assigned a bit in the object->flags (which means it can only traverse from a very small limited number of tips, like 30 or so), which I once planned to extend to arbitrary number of tips by storing these bits in commit slab, but it never materialized. > So I don't think it would be impossible to make this a mode of rev-list. > And that mode might even provide flexibility for other similar > operations, like a mass "git rev-list --cherry-mark"[1]. But it is a > pretty big departure from the current rev-list traversal (to my mind, > especially the "keep walking past UNINTERESTING part). I don't mind it > as its own command. I agree this is not a good fit for the mental model of rev-list or the revision.c::get_revision() traversal. Thanks.
