send-pack: read "unpack" status even on pack-objects failure
commitba69f92db6033d6187414c57547e8f79d6aa7f1b
authorJeff King <peff@peff.net>
Tue, 7 Mar 2017 13:38:51 +0000 (7 08:38 -0500)
committerJunio C Hamano <gitster@pobox.com>
Tue, 7 Mar 2017 22:57:39 +0000 (7 14:57 -0800)
treee6630463540460370dc698b03e73fdd09cf8e8cc
parent40d05d04dd338f80b5392e8dea3a5c854798351e
send-pack: read "unpack" status even on pack-objects failure

If the local pack-objects of a push fails, we'll tell the
user about it. But one likely cause is that the remote
index-pack stopped reading for some reason (because it
didn't like our input, or encountered another error). In
that case we'd expect the remote to report more details to
us via the "unpack ..." status line. However, the current
code just hangs up completely, and the user never sees it.

Instead, let's call receive_unpack_status(), which will
complain on stderr with whatever reason the remote told us.
Note that if our pack-objects fails because the connection
was severed or the remote just crashed entirely, then our
packet_read_line() call may fail with "the remote end hung
up unexpectedly". That's OK. It's a more accurate
description than what we get now (which is just "some refs
failed to push").

This should be safe from any deadlocks. At the point we make
this call we'll have closed the writing end of the
connection to the server (either by handing it off to
a pack-objects which exited, explicitly in the stateless_rpc
case, or by doing a half-duplex shutdown for a socket). So
there should be no chance that the other side is waiting
for the rest of our pack-objects input.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack.c