git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

Previous: Junio C HamanoNext: Junio C Hamano
Message 17 of 19 in “revision: add --maximal option”
  1. revision: add --maximal optionDerrick Stolee via GitGitGadget, Jan 18, 2026
  2. Johannes SixtJan 18, 2026
  3. Derrick StoleeJan 18, 2026
  4. Johannes SixtJan 19, 2026
  5. Derrick StoleeJan 19, 2026
  6. Johannes SixtJan 19, 2026
  7. Junio C HamanoJan 20, 2026
  8. Derrick StoleeJan 22, 2026
  9. revision: add --maximal-only optionDerrick Stolee via GitGitGadget, Jan 22, 2026
  10. Junio C HamanoJan 22, 2026
  11. Derrick StoleeJan 22, 2026
  12. Junio C HamanoJan 22, 2026
  13. Johannes SixtJan 23, 2026
  14. Junio C HamanoJan 23, 2026
  15. Derrick StoleeJan 23, 2026
  16. Junio C HamanoJan 23, 2026
  17. Derrick StoleeJan 28, 2026
  18. Junio C HamanoJan 29, 2026
  19. Derrick StoleeJan 29, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.