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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2026, 00:22 UTC
Message-ID: <xmqqo6mp3zft.fsf@gitster.g>
In-Reply-To: <1ce18cac-f988-4741-b9dd-6c1cf2d4e6af@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Johannes Sixt <j6t@kdbg.org> writes:

Show 19 quoted lines

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