2 ms·
Yep. Git bisect automatically does a binary search to find the earliest breaking commit. You can either test each version manually or, if you have a script that
by globular-toast 3y ago
Yep. Git bisect automatically does a binary search to find the earliest breaking commit. You can either test each version manually or, if you have a script that will pass or fail, like a unit test, you can tell git and it will do everything automatically. I love it when I get to use git bisect.
- amboar 3y agoA handy trick I've developed is using`git bisect` to solve otherwise intractable rebase conflicts: https://codeconstruct.com.au/docs/bisect-intractable-rebase-conflicts/ https://codeconstruct.com.au/docs/bisect-intractable-rebase-...
- eru 3y agoYou might want to combine this with enabling rerere.
- amboar 3y agoYeah, I have rerere turned on However, it's not directly beneficial for the process outlined. With what I wrote about you only solve a given conflict at the end of a complete bisect run, not at each bisection point inside a run. The bisect/cherry-pick process is only used to determine whether conflicts do or don't happen at a given upstream commit. Usually you will solve a specific conflict only once, regardless of whether rerere is enabled.