On Wed, Jan 12 2022, Elijah Newren wrote: > On Wed, Jan 12, 2022 at 10:06 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Elijah Newren <newren@xxxxxxxxx> 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.
