From: Derrick Stolee Date: Fri, 23 Jan 2026 16:55:49 GMT Subject: Re: [PATCH v2] revision: add --maximal-only option Message-ID: In-Reply-To: On 1/23/2026 10:58 AM, Junio C Hamano wrote: > Johannes Sixt writes: > >> 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. Interesting. Thanks for the correction. So we _do_ have a way to get this information for a range that doesn't have negative refs or other custom walk modifiers (and this implementation would be faster for this case). My patch includes test cases that are not covered by the merge-base command. I don't think it would be valuable to extend the merge-base command with even more cases that don't actually output merge-bases / intersections. Thanks, -Stolee