Hi Junio, On Mon, 11 Nov 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > And I agree that this sidetrack is totally irrelevant for the patch > > under discussion. > > > > I do think, however, that the discussion of "we wanted to do it the > > other way, but when we tried, it did not work" is relevant, even if I > > shortened it to "we use a different approach than previous conversions, > > because that previous approach would not work". > > Regardless of the language the scripted version was written in, I > think the '--helper' approach is always the poorer choice between > the two [*1*]. It limits the modular decomposition to what suits the > original language, the impedance mismatch between the original and > target language forces us to unnatural style of inter module > communication, and the unnatural interface layer, which we know has > to be discarded at the end, must be written [*2*]. > > So, I'd prefer to see "because this is a better way in the longer > term" over "because the --helper approach would not work". Hmm. I feel distinctly unheard. It may appear compelling, conceptually, to shun the `--helper` approach, but the more important reality is that it is the only one that makes an incremental conversion possible at all. It took an entire month of 60-hour weeks to complete the conversion of `git add -i`/`git add -p` to C, and only at the very end was I able to run the test suite with `GIT_TEST_ADD_I_USE_BUILTIN=true` and see it pass. That is an awfully long time, and you know fully well that this amount of work equates to three to four Outreachy/GSoC seasons. That would be an insane amount of time to go without the confidence of a passing test suite. In contrast, we were able to complete the conversions of the interactive rebase as well as of `git stash` within _a single season_. I attribute a large part of that success to the ability to keep the tests green during the incremental conversion _because of_ the `--helper` approach. So no, I do not think that your suggestion to reword the commit message is something we want to do. Instead, I think the commit message needs to be rephrased until I get the point across clearly. It is indeed _in spite of_ the success of the `--helper` approach that we cannot use it here. Ciao, Dscho > > [Footnote] > > *1* In only one case I would recommend using "--helper" approach, > though. When you are not expecting the developer to be able to > come up with a better split of the program into modules than how > the scripted version is, and you want to ensure that the > developer have something to show when they faild to complete the > project after N weeks. You are a more experienced developer > than an average GSoC student, and there is no pencils-down time, > so the exception would not apply. > > *2* In "git submodule" for example it was quite natural for the > module that gives a list of submodules with its traits the > program cares about to be written as a shell function that > writes the data to its standard output. And consuming modules > sit at the downstream of a pipe, accepting its output. When you > are writing these modules both in C, you wouldn't connect them > with pipe to carry the list of submodules, but a piecemeal > conversion using the "--helper" approach meant that there always > remained _some_ consumer that wants to read from the pipe, so > long after the module lister was rewritten in C, it still needed > to support a mode where it sends its output to the pipe, instead > of just passing an array of structures. >
