On Wed, Aug 17, 2022 at 11:57 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > >> > Expecting a (hopefully final) reroll. > >> ... > > > > Could I vote for just merging it down, as-is? As far as I can tell, > > ... Further, such changes, while likely > > desirable for consistency among Git commands, would likely move us > > away from "faithful conversion from shell to C", and thus is likely > > better to be done as a separate step on top of the existing series > > anyway[4]. > > If this were a faithful conversion, yes, merging it right now can be > one good approach; add a faithful but not very C-like convesion > first and then make it "more like C code" later. > > I however got an impression from the review discussion that it > subtly changes behaviour (IIRC, one thing pointed out was that exit > codes are now different from the original---there may or may not be > others, but my impression was they were all minor like the "exit > code" one). > > My "hopefully final" comment was not about a big rearchitecting > change like use of parse-options API but about adjusting such minor > behaviour diversion so that we can say "This may not be very C-like, > and does not use much of our established API, but it is a fairly > faithful bug-to-bug compatible translation. Let's take it and make > it more like C incrementally". And of course, what was implied in > "hopefully final" was that such adjustments would be tiny, trivial > and can be done without much controversy. After all, I was aware > that the series was otherwise reviewed and received extensive > comments (sorry, I forgot that it was by you). > > Thanks. Ah, gotcha. My impression was that the exit codes did match what the previous shell code had done, but didn't match what other builtins usually return. Perhaps I misread those discussion comments. Thanks for the clarification.
