Re: [PATCH v2 1/2] bisect: output state before we are ready to compute bisection

[Taylor Blau <me@ttaylorr.com>]

On Fri, May 06, 2022 at 01:52:46AM +0100, Chris Down wrote:
> In order to avoid situations like this, make it more clear what we're
> waiting for:
>
>     $ git bisect start d93ff48803f0 v6.3
>     status: waiting for good commit(s), bad commit known

Makes sense. It would be kind of nice to realize that (in your example)
"v6.3" likely wasn't a pathspec that matched any files, either, and
after trying to DWIM it into something sensible, printed an error and
quit.

But I think the behavior here is slightly more subtle, since we really
care about whether or not a pathspec would match any revisions along the
bisection, not just the tips or the currently checked-out revision.

So I think the approach here makes sense.

> +static void bisect_print_status(const struct bisect_terms *terms)
> +{
> +	const struct bisect_state bs = bisect_status(terms);
> +
> +	/* If we had both, we'd already be started, and shouldn't get here. */
> +	if (bs.nr_good && bs.nr_bad)
> +		return;
> +
> +	if (!bs.nr_good && !bs.nr_bad)
> +		printf(_("status: waiting for both good and bad commits\n"));
> +	else if (bs.nr_good)
> +		printf(Q_("status: waiting for bad commit, %d good commit known\n",
> +			  "status: waiting for bad commit, %d good commits known\n",
> +			  bs.nr_good), bs.nr_good);
> +	else
> +		printf(_("status: waiting for good commit(s), bad commit known\n"));
> +}

Could or should these printf()'s be advise() calls instead? That would
make it easier for users to turn them off if they don't want the extra
output. At the very least, we should make sure that they are sent to
stderr to discourage scripting around them.

Thanks,
Taylor