Re: [PATCH 0/8] ahead-behind: new builtin for counting multiple commit ranges

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 9, 2023, 21:51 UTC
Message-ID: <xmqqv8j98uga.fsf@gitster.g>
In-Reply-To: <ZAmk9V54c/jIbJ65@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

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

Show 6 quoted lines

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