4 ms·
> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? Afaik, git-bisect is aware of branches and merges. Bu
by exDM69 9y ago
> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges?
Afaik, git-bisect is aware of branches and merges.
But there are two drawbacks to not rebasing/squashing: 1) the number of extra commits. Although bisecting is O(log N), it still adds up if it takes a long time to run the tests. 2) if there are any commits that don't build or have to be skipped (git bisect skip) because of other reasons, the number of steps to bisect increases.
It's a good idea to ensure that any commit that goes to master branch will pass all tests or at least compile. Failure to do so will make git-bisect a lot less useful.
- kobeya 9y agoIf true, the the whole claim that nonlinear histories break git-bisect is bunk.
- JoshTriplett 9y agoNon-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.
- AstralStorm 9y agoIt will work just fine, you just might have to call git bisect skip a time or two or run it more than once.
- JoshTriplett 9y agoThat's not "fine"; bisect takes long enough when you expect it to work consistently. And that assumes the code fails at build time, rather than mysteriously at runtime. That also breaks the ability to do automated bisects. I don't think it's at all unreasonable, at a minimum, to expect every individual commit to build and to pass tests.