Re: [PATCH v2] revision: add --maximal-only option
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Jan 28, 2026, 14:28 UTC
- Message-ID
- <c506f9aa-31c9-4c37-98eb-d60076e2e8f5@gmail.com>
- In-Reply-To
- <xmqqfr7wgq1p.fsf@gitster.g>
On 1/23/26 1:08 PM, Junio C Hamano wrote:
Show 24 quoted lines
> Derrick Stolee <stolee@gmail.com> writes: > >> 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). > > Perhaps. If so, perhaps we can improve --maximal-only (and possibly > rename it to --independent? I dunno about this part) by special > casing the logic, and then steer people to use the new implementation > that can use negative ends, deprecating "merge-base --independent" > (which was written to be a better "show-branch --independent")? > >> 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. > > 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?
Thanks, -Stolee