Re: js/bisect-in-c, was Re: What's cooking in git.git (Aug 2022, #05; Mon, 15)

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2022, 18:57 UTC
Message-ID: <xmqqtu6avgub.fsf@gitster.g>
In-Reply-To: <CABPp-BFAERLt_z-D=7gbXWVA9JgsqTP_2iW9BLe5S=YbsQ1V6w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 9 quoted lines

>> >  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.