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?
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.
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.
I agree I don't like it either.