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

From: Derrick Stolee <[email-masked]>
Date: Wed, 28 Jan 2026 09:28:49 -0500

On 1/23/26 1:08 PM, Junio C Hamano wrote:
> Derrick Stolee <[email-masked]> writes:
> 
>> Interesting. Thanks for the correction. So we _do_ have a way to
>> get this information for a range that doesn't have negative refs
>> or other custom walk modifiers (and this implementation would be
>> faster for this case).
> 
> Perhaps.  If so, perhaps we can improve --maximal-only (and possibly
> rename it to --independent?  I dunno about this part) by special
> casing the logic, and then steer people to use the new implementation
> that can use negative ends, deprecating "merge-base --independent"
> (which was written to be a better "show-branch --independent")?
> 
>> My patch includes test cases that are not covered by the
>> merge-base command. I don't think it would be valuable to extend
>> the merge-base command with even more cases that don't actually
>> output merge-bases / intersections.
> 
> 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?

Thanks,
-Stolee