Again, git vs. SVN. Last time, it was big win for git. And guess what, git will strike again.
I mean nobody is perfect (expect Linus, but there is just one – as he mentioned once), so we actually fail writing bugfree code. Therefore we end up sitting in front of a huge code base trying to figure out what’s wrong. Thanks to our agile development process we usually end up fixing code we are not into.
So the facts:
- We don’t know the code
- We don’t have a clue where to search
- We are lazy
bisect
Okay, if we drop 1. and 2. we still have to find out what went wrong. So as we tend to get our evening beer fast and don’t want to waste time, we use git bisect to find out when the problem was introduced.
Assume following commit history:
a –> a’ (bug introduced) –> b –> a” –> c
When we bisect the problem, we will end up doing a quick search on the commits, marking buggy commits/trees bad and those that work fine good. This means, we mark c as good, then git will take us to a. We mark that commit as good, which will git move to b. If we mark b bad, git knows that a’ must introduce the bug. Than just view the diff and you might know where to find the bad code and how to fix it.
Well, as long nobody trashed the history with their ‘fixed a hundred bugs’ commits, containing like thousends of unrelated changes. In those cases, just bisect your collegue. git vs. SVN: 2:0
take it with humour