Re: git bisect with temporary commits

Jeff King [off-list ref] writes:

quoted

You should instead tell git that HEAD^ is good, since that is what git
asked you to test.

Another alternative is to use "git cherry-pick -n" to create a working
tree state that you can test, but leave HEAD at the original commit.
Then "git bisect good" does the right thing.

I was about to say the same, and "bisect good" at that point does
mark the correct commit, but does it always do the right thing?  I
think the procedure must be

	git cherry-pick -n $the_fixup
        test
        git reset --hard
        git bisect good (or bad)

for it to always work, which is not all that different from

	git cherry-pick $the_fixup
        test
        git reset --hard HEAD^
        git bisect good (or bad)

On Mon, Dec 14, 2015 at 01:17:03PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

quoted

You should instead tell git that HEAD^ is good, since that is what git
asked you to test.

Another alternative is to use "git cherry-pick -n" to create a working
tree state that you can test, but leave HEAD at the original commit.
Then "git bisect good" does the right thing.

I was about to say the same, and "bisect good" at that point does
mark the correct commit, but does it always do the right thing?  I
think the procedure must be

	git cherry-pick -n $the_fixup
        test
        git reset --hard
        git bisect good (or bad)

Hmm, you're right. I assumed "git bisect good" would do the equivalent
of "git checkout -f", but it doesn't. I guess it has been long enough
since I have had to cherry-pick a fix that I completely forgot that bit.

It might be convenient if bisect did pass "-f" to checkout, but I guess
it would also be destructive if you had hand-tweaks you forgot to save.

-Peff