Re: [PATCH 05/13] bisect run: keep some of the post-v2.30.0 output
- From
Đoàn Trần Công Danh <congdanhqx@gmail.com>
- Date
- Nov 8, 2022, 01:26 UTC
- Message-ID
- <Y2mwN3bpaiN/7vJh@danh.dev>
- In-Reply-To
- <221107.86k046tp8p.gmgdl@evledraar.gmail.com>
On 2022-11-07 22:40:33+0100, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 43 quoted lines
>
> On Sun, Nov 06 2022, Đoàn Trần Công Danh wrote:
>
> > From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> >
> > Preceding commits fixed output and behavior regressions in
> > d1bbbe45df8 (bisect--helper: reimplement `bisect_run` shell function
> > in C, 2021-09-13), which did not claim to be changing the output of
> > "git bisect run".
> >
> > But some of the output it emitted was subjectively better, so once
> > we've asserted that we're back on v2.29.0 behavior, let's change some
> > of it back:
> >
> > - We now quote the arguments again, but omit the first " " when
> > printing the "running" line.
> > - Ditto for other cases where we emitted the argument
> > - We say "found first bad commit" again, not just "run success"
>
> So, something you refactored here was that there's now a
> do_bisect_run(), and:
>
> > -static int do_bisect_run(const char *command, int argc, const char **argv)
> > +static int do_bisect_run(const char *command, int argc UNUSED, const char **argv UNUSED)
> > {
> > struct child_process cmd = CHILD_PROCESS_INIT;
> > - struct strbuf buf = STRBUF_INIT;
> > + const char *trimed = command;
> >
> > - strbuf_join_argv(&buf, argc, argv, ' ');
> > - printf(_("running %s\n"), buf.buf);
> > - strbuf_release(&buf);
> > + while (*trimed && isspace(*trimed))
> > + trimed++;
> > + printf(_("running %s\n"), trimed);
> > cmd.use_shell = 1;
> > strvec_push(&cmd.args, command);
> > return run_command(&cmd);
>
> Instead of trimming with strbuf_ltrim() we're now using this loop, but
> in any case, this has had the effect that you're only fixing one of many
> of the output changes. We're still adding this leading whitespace to the
> other messages we emit.Sorry, I can't follow, we're fixing in do_bisect_run, which meant we fixed all of the output changes for leading whitespace, no?
'do_bisect_run' will be called from normal 'git bisect run' iteration and also after receiving code 126/127 for the very first run.
Which is the other cases you're talking about?
> > As note din the preceding commit you've carried here in 03/13 I didn't > have time to come up with tests for those.
-- Danh