From: Derrick Stolee <stolee@gmail•com>
To: Junio C Hamano <gitster@pobox•com>, Johannes Sixt <j6t@kdbg•org>
Cc: git@vger•kernel.org,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail•com>
Subject: Re: [PATCH v2] revision: add --maximal-only option
Date: Fri, 23 Jan 2026 11:55:49 -0500 [thread overview]
Message-ID: <f363c16c-1c36-4485-b1e9-22abe32b3a25@gmail.com> (raw)
In-Reply-To: <xmqqecngjp87.fsf@gitster.g>
On 1/23/2026 10:58 AM, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg•org> 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
next prev parent reply other threads:[~2026-01-23 16:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-18 2:34 [PATCH] revision: add --maximal option Derrick Stolee via GitGitGadget
2026-01-18 9:05 ` Johannes Sixt
2026-01-18 18:27 ` Derrick Stolee
2026-01-19 11:15 ` Johannes Sixt
2026-01-19 16:44 ` Derrick Stolee
2026-01-19 19:05 ` Johannes Sixt
2026-01-20 0:22 ` Junio C Hamano
2026-01-22 15:08 ` Derrick Stolee
2026-01-22 16:05 ` [PATCH v2] revision: add --maximal-only option Derrick Stolee via GitGitGadget
2026-01-22 21:44 ` Junio C Hamano
2026-01-22 22:15 ` Derrick Stolee
2026-01-22 23:11 ` Junio C Hamano
2026-01-23 6:38 ` Johannes Sixt
2026-01-23 15:58 ` Junio C Hamano
2026-01-23 16:55 ` Derrick Stolee [this message]
2026-01-23 18:08 ` Junio C Hamano
2026-01-28 14:28 ` Derrick Stolee
2026-01-29 0:14 ` Junio C Hamano
2026-01-29 14:57 ` Derrick Stolee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f363c16c-1c36-4485-b1e9-22abe32b3a25@gmail.com \
--to=stolee@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=j6t@kdbg$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox