Re: [PATCH] Bisect: add checks at the beginning of "git bisect run".

From: Junio C Hamano <junkio@cox.net>
Date: Mar 27, 2007, 05:46 UTC
Message-ID: <7vmz1zs0g5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070327064957.34dad72a.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

> We may be able to "run" with only one good revision given
> and then verify that the result of the first run is bad.
> And perhaps also the other way around.

Bisect fundamentally needs one bad commit (nearer to the tip, relative to the good commits if you have any) to work, but there is no technical reason to require a good commit.

If the commit at the tip of 'master' branch is bad, it is entirely possible to start bisection with:

	$ git rev-list --bisect master

It will find a midpoint between the root commit and the HEAD.

However, for a project with long history, if you immediately start bisecting once you give a bad commit, it would translate to this rather awkward command sequence, especially when you already know one good and bad commits:

	$ git bisect start
	$ git bisect bad master
        ... computes the midpoint in the history, which may be
        ... way in the past, and checkout that ancient commit
        ... to test.  however, because you knew a much more
        ... recent commit that is good, you do not bother to
	... test such an ancient one.
	$ git bisect good $known_good_commit
        ... computes the midpoint between $known_good_commit and
        ... master, and checks it out.

For a toy-sized project such as git.git itself, checking out an ancient revision once, only to immediately check out a more recent revision, is not much of an overhead, but as your project grows into real size, such an unnecessary checkout would waste time (because you would need to update thousands of paths, only to immediately discard) and buffer cache (because the more recent, relevant revision would have set of paths much closer to what you originally had than the initial, wasteful checkout of the ancient commit).

So our requirement to have at least one good commit is not a fundamental one, but only a practical one.

We could give an --immediate (or --no-good) option to 'git bisect bad' to start bisecting as soon as you give a single bad commit. It might turn out that the commits you test are bad all the way down to the root commit, though ;-).