Re: [PATCH v2 1/2] bisect: output state before we are ready to compute bisection
flat view
From: Taylor Blau <hidden>
Date: 2022-05-06 02:52:46
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 knownMakes 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.
quoted hunk ↗ jump to hunk
+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