The way you are invoking the test is unnecessarily restrictive.  It requires the test to be embodied in a single shell script, which in many cases the user would have to write just for this purpose.

If instead you would invoke it using

    check_call(['/bin/sh', '-c', build_script])

then `build_script` could be an arbitrary shell command (or even sequence of commands).  Then the user could specifiy something like

    git imerge --build-command='make' [...]

or even

    git imerge --build-command='make test' [...]

Please note that `git bisect --run` does things differently.  It treats all of the `git bisect` arguments following the `--run` option as individual words of the command that it will run.  This is more flexible still, and maybe a bit less confusing with respect to shell quoting.  But it makes it harder to parse the `git bisect` command itself, because the command to be invoked is "the rest of the line", so no other options or arguments can follow it on the command line.  Moreover, we will need to serialize the command somewhere, and it is easier to serialize a string than a list of strings.  So I think `git bisect`'s approach is not necessarily a model that `git imerge` should follow.

By the way, deviation from `git bisect`'s style of handling the command is a good reason that our option shouldn't be called `--run`.