From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
git@vger.kernel.org,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Subject: Re: [PATCH v2] revision: add --maximal-only option
Date: Wed, 28 Jan 2026 16:14:07 -0800 [thread overview]
Message-ID: <xmqqqzr9cm28.fsf@gitster.g> (raw)
In-Reply-To: <c506f9aa-31c9-4c37-98eb-d60076e2e8f5@gmail.com> (Derrick Stolee's message of "Wed, 28 Jan 2026 09:28:49 -0500")
Derrick Stolee <stolee@gmail.com> writes:
>> Yup, I do not think show-branch nor merge-base were good home for
>> the feature. We only needed to make reduce_heads_replace()
>> available somewhere, and "git show --maximal-only A B C" might be a
>> much better way to express "show only the independent ones", as it
>> would allow using all kinds of output options the "log" family of
>> commands support.
>
> I explored some of these directions, and I see the value of allowing
> a --maximal-only option to them in the future. I have some concerns
> about them not solving the needs I have that this 'git rev-list'
> implementation provides. I believe that you're suggesting that these
> are other places where a user could benefit from such an option, and
> I agree.
>
> Can we delay such extensions to another series?
Absolutely, as long as we all agree on what the longer term
direction is, which includes educating existing users of
"show-branch --independent" and "merge-base --independent" that
"rev-list --maximal-only" is the future even for their "positive end
only" use cases and it also can work on a history bounded by both
positive and negative ends.
The only small thing we need to decide here in the above is that
"--maximal-only" is understandable as an appropriate name for a
superset of "--independent" by those who are used to what the
latter has been doing for the past 15 years or so.
As long as with such understanding, it can be left to the future to
even advertise this option as a better alternative for existing
"--independent" option in the manual pages of these other two
commands.
THanks.
next prev parent reply other threads:[~2026-01-29 0:14 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
2026-01-23 18:08 ` Junio C Hamano
2026-01-28 14:28 ` Derrick Stolee
2026-01-29 0:14 ` Junio C Hamano [this message]
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=xmqqqzr9cm28.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=j6t@kdbg.org \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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