Thank you.
This fix will also remove git-pythons ability to respond to progress as it happens. However, the fix seems more important for now, and an implementation using poll/select can be done at a later time to get back the real-time consumption of git command progress.

Wonder if this could make the async process output handling easier?

https://pypi.python.org/pypi/shelljob

Or this:

http://amoffat.github.io/sh/

Aside from the magic this one does to make external commands look like python functions (which you don't have to use if you don't want), it also seems to handle async I/O and then exposes a nice interface using either a generator or a callback.

Admittedly, I haven't thoroughly looked at it, maybe because I would try not to pull in an additional dependency.
Trolling through another project of mine, I found code that will do async handling of a processes stdout and stderr, it's not to difficult after all (provided we are on a OS that supports poll().

fdmap = { process.stdout.fileno() : process.stdout,
          process.stderr.fileno() : process.stderr }

poll = select.poll()
READ_ONLY = select.POLLIN | select.POLLPRI | select.POLLHUP | select.POLLERR
CLOSED = select.POLLHUP | select.POLLERR

poll.register(process.stdout, READ_ONLY)
poll.register(process.stderr, READ_ONLY)

closed_streams = set()
while True:
    # no timeout
    poll_result = poll.poll()
    for fd, result in poll_result:
        if result & CLOSED:
            closed_streams.add(fd)
        else:
            # there is something to read - this blocks, but its okay
            handle_line(fdmap[fd].readline())
        # end handle closed stream
    # end for each poll-result tuple

    if len(closed_streams) == len(fdmap):
        break
    # end its all done
# end endless loop

handle_line is the callback in this case which probably has an equivalent in the previous git-python implementation.