Hi Junio, On Tue, 16 Aug 2022, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > I'm all in favor of adding such a good example there, but there is no > > reason to hold back `git merge-resolve` from being implemented in C. > > You did not address the primary point, i.e. why the particular > change is a bad one. Sure, you lost a scripted porcelain or two > that are not used much, but in exchange for what? That is _the_ > issue and you skirt around it. In exchange for what I mentioned already in https://lore.kernel.org/git/qs23r0n8-9r24-6095-3n9n-9131s69974p1@xxxxxx/, i.e. in the part you deleted from the quoted mail: We reduce Git's reliance on POSIX shell scripting, we reduce the number of programming languages contributors need to be familiar with, we open up to code coverage/static analysis tools that handle C but not shell scripts, just to name a few. 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 that merely rewriting the `rebase -i` engine in C and nothing else improved the overall run time of p3404 5x on Windows, 4x on macOS and still 3.5x on Linux, see https://lore.kernel.org/git/cover.1483370556.git.johannes.schindelin@xxxxxx/) Yes, Linux sees such an incredible performance boost. Surprising, right? - on Windows, even aside from the performance problems (which I deem reason enough on their own to aim for Git being implemented purely in C), users run into issues where anti-malware simply blocks shell scripts, sometimes even quarantines entire parts of Git for Windows. - 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`? I have. It ain't pretty. And you know that there are easier ways to abuse and deter new contributors than to ask them to do the same. In particular when large amounts of data have to be passed between those processes, typically via `stdio`. - show me the equivalent of CodeQL/Coverity for POSIX shell scripting? ;-) - portability issues dictate that we're not just using your grand father's POSIX shell scripting, but that we limit it to a subset that is opaque to developers unfamiliar with Git project. - as a consequence, our shell scripts are highly opinionated, often using unintuitive idioms such as `&&` chains instead of `set -e`, which makes them unsuitable as examples how to script Git for regular users. - a decreasing number of software developers is familiar with the intricacies of that language, leaving us with tech debt. In short, there is not a single shred of doubt in my mind that avoiding shell scripted parts in Git is a really good goal to have for this project. > The series makes us lose all strategies that are actively tested > that are spawned as a subprocess, which is the way all third-party > strategies will be used. Then have that even-simpler-than `git-merge-resolve.sh` example be tested as part of the test suite. That's what the test suite is for. > After this, we have less test coverage of the codepaths we care about, > which is *not* a scripted "resolve" strategy, but the code that runs > third-party strategies as externals. It is better to leave the responsibility of test coverage to the test suite, avoiding to ship the corresponding support code to users. tl;dr your concerns are easy to address, without having to incur the price of keeping parts of Git implemented in shell. Ciao, Dscho
