Is `git reset --hard` required before mark the current commit as good or bad during bisect?

Question

In my current workflow, I'm updating/rebasing an ancient patch to work against recent versions of a projetct.

In my current workflow, I use git bisect to find the latest commit which can be used to cleanly apply the patch.

To check if the patch can be cleanly applied, I need to patch the files and check the exit status. This procedure changes the working directory, which is no longer clean.

Before apply the current commit as good or bad, I always use git reset --hard, but this task is annoying. Is it required or git bisect will take care of it for me?

Answer 1

It is a good idea to do a git reset --hard as you have been doing.

If the local changes are not affected by the checkout then it does not matter, they will just "ride along with you".

However if your local changes would be overwritten by a checkout it will create an error

$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
error: Your local changes to the following files would be overwritten by checkout:
        README
Please, commit your changes or stash them before you can switch branches.
Aborting

Answer 2

I've been in exactly the same situation a few times. It is best for the tree to be in a clean state before "warping" to a completely different revision.

I ended up putting the patch into a stash.

Usually, in a bisecting situation, a good approach is to put the iteration into a single command line, which can be easily repeated from the shell history. E.g.:

$ if git stash pop ; then <command to do a clean build and test>; git stash save; fi

Then usually all that is left to do is git bisect good or git bisect bad, and re-run the above at the next tested revision. If the stash doesn't apply (the if fails), you have to either resolve it, or just declare the revision untestable with git bisect skip.