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.
