I've seen this once or twice, and at least one user is reporting running into it rarely:
http://pastebin.com/uJYV7iDY
This is somewhat similar to an issue I was able to reproduce quasi-reliably earlier on, in D7558.
D7558 suggests that Git is sensitive to the order in which we close pipes. My guess is that we need to close something which we aren't currently closing explicitly, and 95% of the time that's fine because it tears down before the connection tears down, but 5% of the time we lose a race and end up with this error.
Digging around the Git source code a bit, there's an envvar you can define to get packet-level information:
GIT_TRACE_PACKET=1 git pull
If this //is// a race, I'd expect `git` to receive all of the data whether it hits the fatal or not. That would tend to support the theory that this is an out-of-order-teardown issue.