summaryrefslogtreecommitdiff
path: root/t/t5100
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-03-07 08:38:51 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-03-07 14:57:39 -0800
commitba69f92db6033d6187414c57547e8f79d6aa7f1b (patch)
treee6630463540460370dc698b03e73fdd09cf8e8cc /t/t5100
parentsend-pack: improve unpack-status error messages (diff)
downloadtgif-ba69f92db6033d6187414c57547e8f79d6aa7f1b.tar.xz
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>
Diffstat (limited to 't/t5100')
0 files changed, 0 insertions, 0 deletions