4 ms·

Bisect on first-parent? Seems like a script exists (haven't tried): https://gist.github.com/ayust/2040290 https://gist.github.com/ayust/2040290

• eequah9L 8y ago
  Wouldn't this mean you just find the merge that caused the regression? The merge itself might bring in an awful lot of changes (of a single topic).
  • zbentley 8y ago
    I think that’s desirable. First and foremost, you want to know whose work (in this case, a merged branch) broke yours. Afterwards you might want to drill into what specific piece (in this case commit) of that work was responsible, which can be achieved by bisecting the branch’s non-auto-merge/non-rebase history; this usually gets you close enough to “where the bug was actually written” in my experience, without requiring a switch to a specific workflow of what a commit is supposed to represent/how committed code should behave.
  • Joky 8y ago
    The merge won't bring more changes than if the PR was squashed in a single commit though. Hopefully if you have a test broken and the PR merged two commits: one that refactored the code and the second one that leveraged the refector to change the behavior, you can easily try to revert the latter to check if it fixes the problem. The commit is smaller, easier to re-review, and the bug likely easier to spot.