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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

Hi Elijah,

On Tue, 16 Aug 2022, Elijah Newren wrote:

> On Tue, Aug 16, 2022 at 3:49 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 15 Aug 2022, Junio C Hamano wrote:
> >
> > > * js/bisect-in-c (2022-06-27) 16 commits
> > >  - bisect: no longer try to clean up left-over `.git/head-name` files
> > >  - bisect: remove Cogito-related code
> > >  - Turn `git bisect` into a full built-in
> > >  - bisect: move even the command-line parsing to `bisect--helper`
> > >  - bisect: teach the `bisect--helper` command to show the correct usage strings
> > >  - bisect--helper: return only correct exit codes in `cmd_*()`
> > >  - bisect--helper: move the `BISECT_STATE` case to the end
> > >  - bisect--helper: make `--bisect-state` optional
> > >  - bisect--helper: align the sub-command order with git-bisect.sh
> > >  - bisect--helper: using `--bisect-state` without an argument is a bug
> > >  - bisect--helper: really retire `--bisect-autostart`
> > >  - bisect--helper: really retire --bisect-next-check
> > >  - bisect--helper: retire the --no-log option
> > >  - bisect: avoid double-quoting when printing the failed command
> > >  - bisect run: fix the error message
> > >  - bisect: verify that a bogus option won't try to start a bisection
> > >
> > >  Final bits of "git bisect.sh" have been rewritten in C.
> > >
> > >  Expecting a (hopefully final) reroll.
> > >  cf. <20627.86ilolhnnn.gmgdl@evledraar.gmail.com>
>
> Junio: This link came up dead for me; I think the intended link was
> 220627.86ilolhnnn.gmgdl@evledraar.gmail.com ?

I had mentioned this in
https://lore.kernel.org/git/s3726r9p-r96o-7793-0qrq-o54rs4npr972@tzk.qr/
but failed to ask Junio to change it in the What's cooking mails. Thank
you for pointing it out, too.

> > >  source: <pull.1132.v4.git.1656354677.gitgitgadget@gmail.com>
> >
> > I had another look at the thread and did not see any feedback that focuses
> > on the actual scope of the patch series. Conversions from scripted parts
> > of Git to built-ins are always a bit finicky (and hard to review, I
> > admit).
> >
> > Therefore I would like to move the status to "needs review".
> >
> > I do not think that there are any major issues with it (Ævar's feedback
> > notwithstanding, it focuses on tangents that should be addressed after the
> > conversion, to avoid losing focus), but I would love to see a thorough
> > review of the conversion to avoid obvious regressions like the one in the
> > built-in interactive `add` I had to fix recently.
>
> I reviewed it --
> https://lore.kernel.org/git/CABPp-BEOX+zxR9-yyx-EaiOV-Z9yD0YP_Kwvu4iGB8enz40XXQ@mail.gmail.com/.
> I looked over the subsequent iterations too, and they still look good
> to me.

Ooops. I am sorry for misrepresenting the situation. I honestly had
forgotten that the patch series did, in fact, receive a good and thorough
review.

My apologies and thank you so much for all your help!
Dscho