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

[Junio C Hamano <junkio@cox.net>]

Christian Couder <chriscool@tuxfamily.org> writes:

> So while we are at it, what about a new subcommand "git bisect test" that 
> could be used like this:

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:

> git bisect test good_rev my_script

compared to:

> my_script || {
> 	git bisect start &&
> 	git bisect bad &&
> 	git bisect good good_rev &&
> 	git bisect run my_script
> }

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