Re: [PATCH v2] revision: add --maximal-only option

From: Derrick Stolee <stolee@gmail.com>
Date: Jan 29, 2026, 14:57 UTC
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:

Show 24 quoted lines

> 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