From: Johannes Sixt <j6t@kdbg.org>
Date: Fri, 23 Jan 2026 06:38:08 GMT
Subject: Re: [PATCH v2] revision: add --maximal-only option
Message-ID: <13ff1d94-401e-4fa7-b247-fe8396ca9970@kdbg.org>
In-Reply-To: <7daff220-f93a-463a-b586-dd876b51edae@gmail.com>

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?

-- Hannes