From: Derrick Stolee <stolee@gmail.com>
Date: Thu, 29 Jan 2026 14:57:56 GMT
Subject: Re: [PATCH v2] revision: add --maximal-only option
Message-ID: <9193fab6-f7e9-41ab-bf76-c868feb86db1@gmail.com>
In-Reply-To: <xmqqqzr9cm28.fsf@gitster.g>

On 1/28/2026 7:14 PM, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
> 
>>> Yup, I do not think show-branch nor merge-base were good home for
>>> the feature.  We only needed to make reduce_heads_replace()
>>> available somewhere, and "git show --maximal-only A B C" might be a
>>> much better way to express "show only the independent ones", as it
>>> would allow using all kinds of output options the "log" family of
>>> commands support.
>>
>> I explored some of these directions, and I see the value of allowing
>> a --maximal-only option to them in the future. I have some concerns
>> about them not solving the needs I have that this 'git rev-list'
>> implementation provides. I believe that you're suggesting that these
>> are other places where a user could benefit from such an option, and
>> I agree.
>>
>> Can we delay such extensions to another series?
> 
> Absolutely, as long as we all agree on what the longer term
> direction is, which includes educating existing users of
> "show-branch --independent" and "merge-base --independent" that
> "rev-list --maximal-only" is the future even for their "positive end
> only" use cases and it also can work on a history bounded by both
> positive and negative ends.

I agree to this direction and have some drafts in this direction.

> The only small thing we need to decide here in the above is that
> "--maximal-only" is understandable as an appropriate name for a
> superset of "--independent" by those who are used to what the
> latter has been doing for the past 15 years or so.

My strong preference for using the word "maximal" somewhere over
continued reliance on "independent" is that a set of commits can
be "mutually independent" without any of the commits actually
being maximal within the range.

Here's an example:

    A       B
    |\     /|
    D E   F G
     \ \ / /
      H I J
       \|/
        K

In this commit history graph, each row is an "independent" set of
commits:

	{ A, B }
	{ D, E, F, G }
	{ H, I, J }
	{ K }

and some sets like { A, F, J } are also independent.

Only A and B are "maximal" commits within the history.

I describe this through an example mostly because I don't feel that
I've adequately described this distinction in this thread and
would not feel satisfied in my arguments without it.

With my reasoning more completely described, I am more ready for
someone to overrule my opinion with the argument that "independent"
has enough historical context to mean "a maximal independent set".

> As long as with such understanding, it can be left to the future to
> even advertise this option as a better alternative for existing
> "--independent" option in the manual pages of these other two
> commands.

The other, more complicated, task is to have the rev-list command
use the algorithm that backs 'git merge-base --independent' when
the input range and options is appropriate for that purpose. This
performance-only feature will require more careful construction
and review.

Thanks,
-Stolee