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

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> 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.