Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > To reiterate why reducing the reliance on POSIX shell scripting is a good > thing: > > - we pay a steep price in the form of performance issues (you will recall Irrelevant. Who uses resolve these days? > - have you ever attempted to debug a Git invocation that involves spawning > a shell script that in turn spawns the failing Git command, using `gdb`? Remember, I have been doing this longer than you have, so of course I have, but I do not think it is relevant. An external program as a merge strategy does not have to be written in shell, but third-party strategies can be written in anything, so some who choose to do so may still have to. There is no avoiding that. What our contributors, new and old, need to do is to maintain the codepath that spawns these third-party strategy programs working. There were two steps I gave review messages to, and the one I had more trouble with was actually not the [08/14] you are making big fuss about. It was the "we no longer spawn resolve or octopus" step(s). If we really want to rewrite "resolve" in C, while I think there are better ways to use our resources, rewriting it by itself would not _hurt_ the project all that much, as long as we keep it an external program. And by "maintain the codepath working", we would want to catch silly mistakes while "refactoring", like the one we had when we changed the underlying machinery to spawn hooks in a recent release, without caring (I wouldn't say "without knowing"; those who did and reviewed the change including me didn't even think about how the standard I/O streams are seen by hook scripts and how they react to them). Just like tests around small toy sample hooks did not catch the regression, "a small toy sample that is only spawned in a test piece or two to pretend to be a merge strategy program" would not be a good substitute for running something real.
