Interesting.  So "the source at this commit cannot be built or cannot be tested" is treated as success as far as `git imerge` is concerned?  This is different than `git bisect`: there, return value 125 is handled as a third, "indeterminate" state and it is treated differently in subsequent logic.

We could also handle this return code specially during bisection.  It could be treated as "something is fishy.  Don't treat it as a failure, as long as the status of other tests are definitive".  So if an earlier merge is found to FAIL definitively, then we would continue to the left of *that* merge.  And if a later merge is found to SUCCEED definitively, then we would continue to the right of *that* merge.  And if an indeterminate merge is found at the boundary between SUCCEED and FAIL, then we would treat the indeterminate status the same as a FAIL.

But without some kind of special handling, I don't see the value of treating return code 125 specially.  The test script could just as well return 0 because it would have the same end result.