[kovrik]

Yes, that is a problem.

On the other hand, with your approach you are going to have revisions that won't even build/compile.

If you have automatic builds or/and unit/integration tests, then you'll have failed builds every time you have a merge conflict.

Also, you are kind of 'polluting a well': what if meanwhile someone merges that revision into his/her branch? Or what if you have automatic merges configured?

[phpnode]

Presumably in this model the dev wouldn't push their branch until the merge is actually complete, and there's presumably a convention like prepending `[CONFLICT]` to those commits to discourage people from checking them out directly.

[sethammons]

And you just lost git bisect

[paulddraper]

Not really; git bisect skip still works.

I agree I don't like it either.

[pkamb]

`git bisect skip`

[sethammons]

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

[jzwinck]

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

[robinson7d]

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.

[michaelmior]

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

[dantiberian]

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

[masklinn]

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