Hi Junio, On Wed, 31 Aug 2022, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > And it is that doubling of work that I tried to avoid when implementing > > the built-in version. The bug came about because the full diff call wasn't > > using the `--ignore-submodules=dirty` option, and that's what I missed. > > > > This is maybe more interesting a story for the cover letter, to be able to > > understand how this bug was introduced, and maybe to offer an opportunity > > for others (in addition to myself) to learn from my mistake. > > Yup, the moral of the story is premature optimization bites because > we are not always careful ;-) Yes. Maybe even more generally: trying to do too many things at once is prone to introduce bugs. > Anyhow, I am getting an impression that the behaviour of the next > iteration would be much closer to the original, which is excellent. Yep! > We have seen too many "ah, this is broken and here is a fix that is > appropriate in the context of how the new C version does it", not > "ok, let's make the whole thing behave more like what we used to > have". Unfortunately so. It is a fine line, and not always possible to tread safely, between trying to stay close to the original and trying to learn the lesson from Elijah that converting scripts to C without playing to C's strengths causes a lot of hiccups later on. There are probably better alternatives for prototyping Git functionality than using either an untyped language that cannot hold complex data structures in memory or a language to which everything looks like a map ;-) Ciao, Dscho
