Git fetch/pull/clone hangs on receiving objects

Question

When fetching or pulling from git repositories, or cloning a repository, I get to this point:

remote: Counting objects: 6666, done.
remote: Compressing obje         


        

Answer 1

On Mac, git fetch should be more resistant to this kind of issue, with Git 2.22 (Q2 2019): On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX), the upload-pack that runs on the other end that hangs up after detecting an error could cause "git fetch" to die with a signal, which led to a flakey test.
"git fetch" now ignores SIGPIPE during the network portion of its operation (this is not a problem as we check the return status from our write(2)s).

See commit 1435889 (03 Mar 2019), and commit 37c8001 (05 Mar 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 27cdbdd, 20 Mar 2019)}

fetch: ignore SIGPIPE during network operation

The default SIGPIPE behavior can be useful for a command that generates a lot of output: if the receiver of our output goes away, we'll be notified asynchronously to stop generating it (typically by killing the program).

But for a command like fetch, which is primarily concerned with receiving data and writing it to disk, an unexpected SIGPIPE can be awkward. We're already checking the return value of all of our write() calls, and dying due to the signal takes away our chance to gracefully handle the error.

On Linux, we wouldn't generally see SIGPIPE at all during fetch. If the other side of the network connection hangs up, we'll see ECONNRESET.
But on OS X, we get a SIGPIPE, and the process is killed.

Let's ignore SIGPIPE during the network portion of the fetch, which will cause our write() to return EPIPE, giving us consistent behavior across platforms.