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

From: Johannes Sixt <j6t@kdbg.org>
Date: Jan 19, 2026, 11:15 UTC
Message-ID: <1ce18cac-f988-4741-b9dd-6c1cf2d4e6af@kdbg.org>
In-Reply-To: <b46885b1-5781-43d8-8751-d85048c45e5e@gmail.com>

Am 18.01.26 um 19:27 schrieb Derrick Stolee:

Show 14 quoted lines

> On 1/18/26 4:05 AM, Johannes Sixt wrote:
>> Am 18.01.26 um 03:34 schrieb Derrick Stolee via GitGitGadget:
>> > The option name is too generic IMHO. How about "--starting-point",
>> "--topmost-only"?  It's function is somewhat parallel to --boundary, but
>> at the positive end of the revision range. Perhaps we can use that as
>> inspiration.
> 
> My perspective is skewed, because "maximal" is a concrete term in the
> world of partially-ordered sets (such as commit history ordered by
> reachability across child-to-parent relationships). It's important to
> distinguish from "starting points" because the inputs to the command
> are a list of starting points, not all of which are maximal within the
> set. In fact, if some positive starting points are reachable from the
> negative starting points, then they are already excluded.

AFAICS, we don't have options named after graph- or set-theoretical terms, but tend to stick to terms established in the Git ecosystem. I assume that "maximal" isn't a meaning that an average Git user would associate with the operation that is performed here.

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.

-- Hannes