From: Derrick Stolee <stolee@gmail.com>
Date: Thu, 22 Jan 2026 15:08:53 GMT
Subject: Re: [PATCH] revision: add --maximal option
Message-ID: <85c6fdce-d48a-4af2-ba19-432885a034ab@gmail.com>
In-Reply-To: <xmqqo6mp3zft.fsf@gitster.g>

On 1/19/26 7:22 PM, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
>> But even if we decide to use "maximal", the option must be named
>> something other than *just* "--maximal"; this is simply too generic.
>> Perhaps "--only-maximal" or "--maximal-only".
>>
>> Other ideas:
>> - --hide-reachable
>> - --range-head
>> - --range-head-only
>> - --most-recent
>> - --most-recent-only
>>
>>> [--maximal]'s interaction with
>>> --boundary is trivial because no boundary commits would be included as
>>> they are necessarily reachable from a maximal commit.
>>
>> So, --boundary --maximal shows only the maximal commits? That sounds
>> unexpected. Boundary commits are shown with additional mark-up; they
>> don't need to be suppressed. But in a first iteration it's probably
>> better to just make the two options incompatible.
> 
> If I am reading the answer to "what is minimal/maximal elements in
> partially ordered set?" correctly, our "--boundary" essentially is
> to show direct parents of those commits that would be shown with the
> (nonexistent) "--minimal-only" option.  So I agree with you that it
> makes perfect sense to make "--boundary" and "--maximal-only"
> incompatible (it is like asking for both "--minimal-only" and
> "--maximal-only" at the same time).

The existence of a --minimal option that doesn't match the mirror
of my suggested --maximal option convinces me to move to
--maximal-only. I will send a v2 shortly that updates this and
moves the documentation next to other filtering options.

I'll also mark --boundary and --maximal-only as incompatible to
avoid confusion.

Thanks,
-Stolee