Re: [PATCH v2] revision: add --maximal-only option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 29, 2026, 00:14 UTC
- Message-ID
- <xmqqqzr9cm28.fsf@gitster.g>
- In-Reply-To
- <c506f9aa-31c9-4c37-98eb-d60076e2e8f5@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
Show 15 quoted lines
>> 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.