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

Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Jan 13, 2022, 09:26 UTC
Message-ID
<220113.86k0f4vuz5.gmgdl@evledraar.gmail.com>
In-Reply-To
<CABPp-BHQdkhAEmTrtc+XMgj5A5ASBVRw0_bXH10NSrMsyRK+oA@mail.gmail.com>
On Wed, Jan 12 2022, Elijah Newren wrote:
Show 22 quoted lines
> On Wed, Jan 12, 2022 at 10:06 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
> ...
>> I however suspect that Ævar didn't mean by "legacy merge plumbing
>> built-in" the strategy backends.  IOW, I had an impression that what
>> is on the chopping block is merge-tree and not merge-recursive.
>>
>> But since you brought up deprecation of recursive, let's spend a few
>> minutes on the topic.
>
> Not sure it matters, but for reference, Ævar explicitly brought up
> merge-recursive.c.  The fuller quote was:
>
>> >> I.e. is it really costing us
>> >> to just leave these "legacy merge" plumbing built-ins and
>> >> merge-recursive.c etc. in place?
>
> Because he brought it up, I decided to address it.  It was unclear to
> me whether he meant builtin/merge-recursive.c or the toplevel
> merge-recursive.c, so I just addressed both.

FWIW what I meant (but clearly didn't make clear enough) is whether we'd deprecate the git-merge-tree(1) command, not whatever powers it under the hood.

I.e. I took the greater discussion here to mean (but may have misunderstood it) that we were talking about the needs for a libgit2-replacing merge plumbing.

The existing git-merge-tree command probably gets us 5% towards that, and I can see how being bug-for-bug compatible with it might be inconvenient in some future on-top-of-ort rewrite and extension of it.

So we probably SHOULD keep it, but I don't think it's a MUST. I.e. if you/someone wrote some more powerful version of it, and keeping it became hard to support I think it would be OK to transition/deprecate it, as presumably its existing users wouldn't be too inconvenienced, or would be happier with the more powerful plumbing tool.

Previous: Elijah NewrenNext: Junio C Hamano
Message 19 of 28 in “Introduce new merge-tree-ort command”
  1. 0/2 Introduce new merge-tree-ort commandChristian Couder, Jan 5, 2022
  2. 1/2 merge-ort: add new merge-tree-ort commandChristian Couder, Jan 5, 2022
  3. Elijah NewrenJan 5, 2022
  4. 2/2 merge-ort: add t/t4310-merge-tree-ort.shChristian Couder, Jan 5, 2022
  5. Elijah NewrenJan 5, 2022
  6. Elijah NewrenJan 5, 2022
  7. Elijah NewrenJan 5, 2022
  8. Christian CouderJan 7, 2022
  9. Elijah NewrenJan 7, 2022
  10. Johannes SchindelinJan 10, 2022
  11. Junio C HamanoJan 10, 2022
  12. Johannes SchindelinJan 11, 2022
  13. Ævar Arnfjörð BjarmasonJan 11, 2022
  14. Elijah NewrenJan 11, 2022
  15. Junio C HamanoJan 12, 2022
  16. Elijah NewrenJan 12, 2022
  17. Junio C HamanoJan 13, 2022
  18. Elijah NewrenJan 13, 2022
  19. Ævar Arnfjörð BjarmasonJan 13, 2022
  20. Junio C HamanoJan 12, 2022
  21. Ævar Arnfjörð BjarmasonJan 13, 2022
  22. Elijah NewrenJan 10, 2022
  23. Elijah NewrenJan 11, 2022
  24. Johannes SchindelinFeb 22, 2022
  25. Johannes SchindelinJan 11, 2022
  26. Elijah NewrenJan 12, 2022
  27. Johannes SchindelinFeb 22, 2022
  28. Johannes SchindelinJan 7, 2022

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.