undefined | Better HN

0 pointssethammons9y ago0 comments

And you just lost git bisect

0 comments

paulddraper9y ago

Not really; git bisect skip still works.

I agree I don't like it either.

pkamb9y ago

`git bisect skip`

sethammonsOP9y ago

The more you know; I'll have to look into that!

jzwinck9y ago

You can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.

robinson7d9y ago

I 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.

michaelmior9y ago

This is resolved if you skip the commits with a conflict instead of marking as good.

dantiberian9y ago

I think you'd want to skip, not mark as good?

masklinn9y 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.

j / k navigate · click thread line to collapse