Re: [PATCH] revision: add --maximal option
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Jan 22, 2026, 15:08 UTC
- 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:
Show 28 quoted lines
> 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