3 ms·

> 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduce

by kobeya 9y ago

> 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? That would resolve this sticking point. > 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Then tell them to go away and come back with a cleaned up PR.

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 ago
  If true, the the whole claim that nonlinear histories break git-bisect is bunk.
  - JoshTriplett 9y ago
    Non-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 ago
      It 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 ago
        That'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.

by kobeya 9y ago

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 ago
If true, the the whole claim that nonlinear histories break git-bisect is bunk.
- JoshTriplett 9y ago
  Non-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 ago
    It 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 ago
      That'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.