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

Christian Couder [off-list ref] 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 ;-).

Le mardi 27 mars 2007 07:46, Junio C Hamano a écrit :

[...]

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 ;-).

Yes, I plan to add some options to git bisect subcommands.

For example "git bisect run" could accept the following options:

--not
mark current revision as bad instead of good and as good instead of bad

--strict
all exit code except 0 and 1 abort the bisect run process

--good <rev1>
--bad <rev2>
use rev1 as good and rev2 as bad

--check or --test
run the script once and then do nothing if the result is good

Are there other options that people want ?

Thanks,
Christian.

Christian Couder [off-list ref] writes:

For example "git bisect run" could accept the following options:

--not
mark current revision as bad instead of good and as good instead of bad

Do you mean this is a useful option when the "run-script"
reports failure with 0 exit and success with non-zero exit?  In
other words, exit code has reversed meanings from the usual?

--strict
all exit code except 0 and 1 abort the bisect run process

This I can understand...

--good <rev1>
--bad <rev2>
use rev1 as good and rev2 as bad

I am not sure what you mean by these two.

--check or --test
run the script once and then do nothing if the result is good

How would you use this?  Presumably this makes the command keep
running while the commit is bad, until you hit a good commit and
then stop.

I wonder why this is useful.

Stopping at a commit that happens to be good, without narrowing
the range all the way down is sometimes useful, as you can
usually guess which one of the remaining commits are likely to
be involved with the problem you are seeing, when the remaining
set is sufficiently narrow.  But how narrow the remaining set is
does not have much to do with your finding a good commit for the
first time.  If you start from a single bad commit at the tip of
10-year old project, you would probably try 5-year old commit,
which may well be good (or maybe it is too old to be relevant)
and then this option would make the cycle stop, and you have
5-year worth of history still left to be bisected.  I am not
sure what the assumed workflow would be after that point.

Le mercredi 28 mars 2007 07:46, Junio C Hamano a écrit :

quoted

--not
mark current revision as bad instead of good and as good instead of bad

Do you mean this is a useful option when the "run-script"
reports failure with 0 exit and success with non-zero exit?  In
other words, exit code has reversed meanings from the usual?

Yes, for example to find when a string first appeared in a file one could 
use:

git bisect run --not grep string my_file

instead of something like

git bisect run ! grep string my_file

or

git bisect run 'grep string my_file ; test $? -ne 0'

quoted

--good <rev1>
--bad <rev2>
use rev1 as good and rev2 as bad

I am not sure what you mean by these two.

For example one could write:

git bisect run --good rev1 --bad rev2 my_script

instead of

git bisect start
git bisect good rev1
git bisect bad rev2
git bisect run my_script

quoted

--check or --test
run the script once and then do nothing if the result is good

How would you use this? 

For example if you know that the last nightly build 
tagged "nightly_2007_03_27" was ok, you could use:

git bisect start
git bisect good nightly_2007_03_27
git bisect run --check make > /dev/null || {
	# extract commit and author email address from "$GIT_DIR/BISECT_RUN"
	# and send flame to author who broke the build with the commit
}

to automatically check that current source code builds ok.

Or you could use it in some test suites to automatically find the first bad 
commit (and be able to flame the author :-) in case one test fails.

Christian.