On Tue, Jan 11 2022, Johannes Schindelin wrote: > Hi Junio, > > On Mon, 10 Jan 2022, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > I am against a new command for what essentially serves the original >> > purpose of `merge-tree`. >> > >> > The fact that `merge-tree` has not seen any work in almost 12 years is >> > testament not only to how hard it was to disentangle the work-tree >> > requirement from the recursive merge (it is one of my favorite >> > counterexamples when anybody claims that you can easily prototype code in >> > a script and then convert it to C), but the fact that there is no user >> > within Git itself (apart from t/t4300-merge-tree.sh, which does not count) >> > speaks volumes about the design of that `merge-tree` tool. >> > >> > So it's only fair to breathe life into it by letting it do what it was >> > meant to do all along. >> >> My "Yup" would not weigh as much as one that Linus (whose original >> merge-tree survived this long without seeing much enhancements) >> might give us, but he is busy elsewhere so you guys have to live >> with mine ;-) >> >> As to its output, I do agree that "we give a tree when it is already >> usable to record in a new commit" is a valuable option to have. The >> original behaviour should be made available somehow, for those who >> built their workflow (including scripts) around it, though. > > No, I don't think it is a good idea to keep the original behavior around > indefinitely, when it is totally unclear whether there actually _is_ any > user of this feature out there. For what it's worth I've used it for some automation at an ex-employer at least once. Grepping through my #*git* IRC logs there's a few mentions of it, and likewise for StackOverflow. I'm not opposed to replacing it, and I think that probably in-the-wild users of it are almost certainly just grepping for the conflict markers to see if there's conflicts, or parsing which files have them etc. So if we can provide a better interface that they can use (or even make git merge-tree a thin wrapper...). > We intentionally broke any existing users of `git-parse-remote.sh` by > removing it, when that feature was much more likely to be used in scripts > than `git merge-tree`. We cannot say on the one hand that we will get rid > of some useful script just because we don't want the maintenance burden > when on the other hand trying to keep support for an operation that is > unlikely to have any users. That does not compute. (And don't get hung up > on the specific example of `git-parse-remote.sh`[...] The specific example or case really matters. We don't have some generic flowchart for deprecating things that applies in all cases. I removed git-parse-remote.sh in a89a2fbfccd (parse-remote: remove this now-unused library, 2020-11-14) and had the opposite impression you're expressing here. I.e. searching around for in-the-wild uses via search engines, stack overflow etc. either found nothing interesting, or just a reflection of ourselves (i.e. generated manpages etc.). That along with its history, i.e. it wasn't *really* meant for out-of-tree exposure if you look at the history of how it came about, it was just made at a time when similar libraries had similar manpages etc. added as a template. Maybe that was the right thing to do, maybe not, but it went out with v2.30.0 and the lack of complaints since then would seem to suggest that I was right that removing it wouldn't be a big deal. Of course it may have broken someone's script somewhere. But an important distinction is that they can get it working again by just copy/pasting that ~100 line shell library into their own script, or calling the underlying commands it was invoking themselves. Which doesn't apply to "git merge-tree" unless we come up with a replacement, and even then a 1=1 port of some in-the-wild code might be much harder, i.e. if it's deeply coupled to parsing the specific output it emits now. So I'd personally be much more hesitant to remove or change that, but of course we might still come up with good reasons for why it's worth it, especially with some advertised deprecation period. And isn't any doubt around that even more reason to just go with Elijah's plan of introducing new plumbing? I.e. is it really costing us to just leave these "legacy merge" plumbing built-ins and merge-recursive.c etc. in place?
