5 ms·
You can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.
by jzwinck 10y ago
You can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.
- robinson7d 10y agoI don't think that would work, but correct me if I'm wrong. As far as I know, git bisect does a binary search along the commits; `good` tells it to look at the latter half, `bad` to look at the former. So suppose you have five commits (1,2,3,4,5), where 1 is the working state, and 3 is a conflict commit. It will start by asking about the middle commit (3), automatically choose `good`, and determine that 3 was the latest working commit (after checking 4, which says `bad`). ---- EDIT: Obviously this is simplified to explain the issue with marking "good" those commits.
- michaelmior 10y agoThis is resolved if you skip the commits with a conflict instead of marking as good.
- dantiberian 10y agoI think you'd want to skip, not mark as good?
- masklinn 10y ago> test function return "good" whenever it sees a commit with merge conflicts That's a terrible idea and would completely break bisect. You should signal "skip" (return code 125) if the commit can not be tested at all.