tags:

views:

52

answers:

2

My usual workflow when starting a git bisect session is:

git bisect start          # start a bisect session
git bisect bad            # I noticed that the current state is broken

Now, often I know that things worked in the past, but I don't know yet which version was good, so I usually want to revert my working tree to an older state, build, test, repeat until I find a working version which I can mark with git bisect good.

What's the best way to do the "revert my working tree to an older state" step? git reset --hard <some_good_rev>? git checkout <some_good_rev>? Something else? Please justify your answer.

+6  A: 

I usually don't know where the good rev is, so I've got to find it. Guess how far back might be good. Let's say, 32 revs. Starting from the tip of a branch, and with clean working directories:

$ git checkout HEAD~32

Run the test. If it's a good rev, start bisecting. If it's not, go back some more:

$ git checkout HEAD~32

Rinse, lather, repeat.

Why "git checkout?" Because "git reset" will change which commit the branch points to as its "tip", but git checkout will not.

Wayne Conrad
Ah, the "~n" notation is a nice trick here; I wondered whether 'checkout' works because it gives me a 'detached head'. I wasn't sure bisect likes that, but apparently it does. Cheers!
Frerich Raabe
A: 

If you don't know for sure any version where the functionality worked (the commit that introduced the functionality?), you seem to lose a lot (all?) of the benefit of a bisect. If you do know that there was at least one commit where the functionality worked, even if it isn't necessarily the most recent commit where the functionality worked, just flag that one as good. Otherwise, you're basically doing a bisect yourself.

jamessan
I apologize for the imprecision; I meant to imply that I *do* know that some past version worked - I just don't know *which*. I added that now to my question.
Frerich Raabe