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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 23, 2026, 15:58 UTC
Message-ID: <xmqqecngjp87.fsf@gitster.g>
In-Reply-To: <13ff1d94-401e-4fa7-b247-fe8396ca9970@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 19 quoted lines

> Am 22.01.26 um 23:15 schrieb Derrick Stolee:
>> Unfortunately, it also says "print a minimal subset" which in some
>> sense is correct by "it cannot be made smaller without losing
>> information" but we actually choose the maximal set there, not a
>> minimal set.
>> ...
>> You are presenting interesting overlaps of terminology and needs.
>> One thing that is different about 'git rev-list --maximal-only' with
>> a list of starting commits is that it wants the maximal set from
>> the _union_ of the histories, instead of the _intersection_ like
>> 'git merge-base --independent' does.
>
> I don't quite understand how a union or intersection come into play
> here. The difference between the two is that `git rev-list
> --maximal-only` permits negative revisions as input, but `git merge-base
> --independent` does not. In the case where the input is only positive
> revisions, the result of --maximal-only should always be exactly
> identical to --independent, right? Even if the revisions are on
> disconnected histories?

Ahh, it is an ancient history that I forgot how the command worked. "merge-base --independent A B C" does not do any "merge-base" computation over the commits A B C and shows the ones that cannot be reached from any other. If it were to compute merge bases across these commits and then find commits, among the computed merge bases, that cannot be reached from any other merge bases, "intersection" might come into play, but I do not think that is what the command does.