Martin von Zweigbergk wrote: > On Thu, Dec 17, 2020, 16:52 Felipe Contreras <felipe.contreras@xxxxxxxxx> > wrote: > > > Junio C Hamano wrote: > > > Many people may stick to just a single tool and may find a single > > > mergetool.autoMerge knob convenient (and it is OK for them if the > > > new behaviour broke a tool they do not use), but for those who use > > > more than one, being able to configure them differently would be > > > valuable. > > > > On what tool would you turn this on, and what tool would you turn this > > off? > > Maybe turn it off for a mergetool smart enough to understand the semantics > of the change? > > Let's say BASE contains a function foo(). LOCAL renames foo() to bar() and > OTHER adds a call to foo(). The tool would need to know that the call to > foo() was added in order to know that it should be renamed in the output. That's true, but that's something we would want in git itself, not the mergetool. If there are no conflicts, "git merge" would simply do the automatic merge, and this magical semantic mergetool would never have an opportunity to run. > I've only skimmed this thread, so I apologize if I've misunderstood the > quotation or if my point has already been brought up. Nobody has made this point. And it's the kind of rationale I was looking for. Cheers. -- Felipe Contreras
