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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Apr 5, 2007, 08:01 UTC
Message-ID: <200704051001.52592.chriscool@tuxfamily.org>
In-Reply-To: <7virck8txp.fsf@assigned-by-dhcp.cox.net>

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

[...]

Show 13 quoted lines

> 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
}

Show 42 quoted lines

> 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