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

[Elijah Newren <newren@gmail.com>]

On Wed, Aug 17, 2022 at 11:57 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

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.