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

Le jeudi 29 mars 2007 08:06, Junio C Hamano a écrit :

[...]

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. 

I understand this.

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.

But I think this is not a specific need. Many people are doing nightly 
builds and it's a good practice, so we should encourage them by making it 
as easy as possible.

Perhaps a new git subcommand instead of a git bisect subcommand.

For a nightly build you want to do something like:

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

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