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

Christian Couder <chriscool@tuxfamily.org> writes:

You are using it as a building block for nightly script, so there are already certain logic around the call to "git bisect" in your script. I do not think we would necessarily want more subcommands to "git bisect", unless the new subcommands truly is generally applicable.

Unlike "run", "test" expects a workflow where there always is one recent good_rev and there might be at most one single breakage introduced since the last nightly build. For that particular use case, it might be handier to be able to write a single line:

compared to:

but it is not useful for use case other than that. Maybe we already know more than one good commits that are on the side branch to limit the bisect space in project specific way.

The thing is, the more you add policy to a building block, the less generally useful the building block becomes. The reason I took "git bisect run" is because for the simplest use case, it can be used without writing a specialized "run script" (you can give "make test" to it, for example). And more importantly, in the case of "run", there is not much policy involved. It is a good command to have in a building block because what it does is purely to automate what the user would perform mechanically by hand anyway. One thing I would want is to keep the bisect subcommands to the minimum, so that people can easily use it as a building block in their automation, without having to hunt through many workflow-specific subcommands that do not suit their particular needs. Catering to their particular needs are better handled in their scripts, including your "I have one known good commit, I do not know if the tip is good, and I want to dig down from the tip only when the tip is bad" case.

If you want to add value to bisect, here are two I can think of, one almost trivial, and the other a bit harder.

(1) One bad commit is fundamentally needed for bisect to run,
    and if we beforehand know more good commits, we can narrow
    the bisect space down without doing the whole tree checkout
    every time we give good commits.  I think it may be a good
    idea to have:

	git bisect start [$bad [$good1 $good2...]] [-- <paths>...]

    as a short-hand for this command sequence:

	git bisect start
        git bisect bad $bad
        git bisect good $good1 $good2...

    That would be a good script-shorterner, without limiting it to
    any specific use scenario.

(2) There is no technical reason to have a good commit for
    bisect to run, other than you _often_ do not want the first
    mid-point checkout before you give good ones to it.  But
    sometimes, you may not know even if something _ever_ worked,
    IOW, even the root commit might not be good.  In such a
    case, being able to bisect having only one bad commit and no
    good commit would be handy.  For this, bisect_next_check
    needs to be tweaked.  Probably a transcript for such a
    feature would go like this:

	$ git bisect start
        $ git bisect bad HEAD
        $ git bisect next ; echo $?
        You need to give me at least one good and one bad revisions,
	with "git bisect good" and "git bisect bad".
	1
	$ git bisect next --without-good
	Bisecting: 4321 revisions left to test after this
	[deadcafedeadcafedeadcafedeadcafedeadcafe] an ancient commit
	$ git bisect bad
	Bisecting: 2152 revisions left to test after this
	[edeadcafedeadcafedeadcafedeadcafedeadcaf] a more ancient commit