That loses a lot of information, though. If you want to bisect to find a particular bug, tracking it down to the merge is a good start, but I'd rather have the actual commit (from the maybe hundreds) that went into the merge. Sure, you can revert the feature, but what if you want to fix the bug?
Bisect knows how to deal with this; you can tell it to ignore a commit that you know is broken for reasons unrelated to the issue upper investigating (and try adjacent ones instead).
What is the point of finding the commit that removed the usage of your dead code? You should only care about the state of master. There is no point trying to prove where the removal happend.
Bisect is great to find the commit that caused a bug, because the commit narrows down the code to inspect to fix the bug.
Maybe I'm missing something here, but git bisect doesn't seem to apply in this case.
If you have a branch which always builds and tests green, you can add a new test, choose a red commit and a green commit and run `git bisect` in a loop to automatically get to the commit that caused the behaviour in that test to regress.
Yes, but if you run git bisect and then try to run your unit tests, a failure that was intentional will tell the bisect to potentially divide the commits at the wrong point.
You'd need to either exclude the test (probably not a great idea) or mark the commits as skippable. Also not a great idea.
Summary: "git bisect bad" on current (broken) build, find a past build that works, mark it as "git bisect good", and git will basically guide you through a binary search to find the last good build before the current broken one.
Git bisect solved a problem I had before. I had exhausted debugging and even println debugging, in the end I had to find out which commit introduced the bug. Once I found the change it was very easy to fix.
Fond memories of the time I used "git bisect" to find a bug, and the commit that introduced it was some breathtakingly-large codebase-reorganisation-but-shouldn't-have-changed-anything-functionally.
Thankfully the commit didn't have my name at the top. I made him fix it.
I have found an almost security hole with it in the dropping of a BC layer which just no one would've expected to do that. And because it was all deleted code tracking down the origin bug any other way is fair impossible.
this is always fun with git-bisect because if you can reliably reproduce the bug it will always leads you exactly to the commit that caused the problem. Nothing worse than tracing for a half hour and... it spits out your name.
In the past, I've committed the unit test like you, branched, rebased the unit test back to some appropriate point in time, and then run git bisect. This avoids applying/resetting at each step, and allows for some trickiness like changing your test to deal with an interface that mutates over the range of commits you're testing. The hash of the errant commit will be different after rebasing of course, but it's easy enough to match it up with the one in the original branch.
I wish there were a guide or some official "this is how to manage your git repository along with your tests so bisect will work wonders" - IIRC, bisect gets tripped up by commits that won't build and also some merges... would be nice to know what exactly to do about those once they're in your history.
If one has pretty good automated tests, it’s possible to automate and pinpoint which commit has the last working version and which commit had the test failure by using git bisect and using the test results as input.
I sometimes use the stash for that: cherry pick the test as a working tree uncommitted change. "git stash" it before every bisect step, then "git pop".
If you need to more fiddling to get things working in each bisected commit, you can launch the process manually with 'git bisect start', then pass in refs to 'git bisect bad' and 'git bisect good' to indicate a known-bad and a known-good commit.
At that point, git will check out the "middle" revision and you can do whatever's needed to decide if you should mark it as either good or bad with 'git bisect [good|bad]'. This will check out the new "middle" - lather, rinse, repeat until you get down to one commit.
When you're done, 'git bisect reset' will take you back to the present.
While this isn't quite as quick as the automated version, it's a lifesaver when tracking down a regression in a library whose dependencies have changed radically (finding what b0rked your tests between Rails 3.0 and 4.0, for instance).
reply