[PATCH 6/6] send-pack: report signal death of pack-objects
- From
Jeff King <peff@peff.net>
- Date
- Mar 7, 2017, 13:39 UTC
- Message-ID
- <20170307133948.x3w6nufae7tbgeka@sigill.intra.peff.net>
- In-Reply-To
- <20170307133437.qee2jtynbiwf6uzr@sigill.intra.peff.net>
If our pack-objects sub-process dies of a signal, then it likely didn't have a chance to write anything useful to stderr. The user may be left scratching their head why the push failed. Let's detect this situation and write something to stderr.
Signed-off-by: Jeff King <peff@peff.net> --- We could drop the SIGPIPE special-case, but I think it's just noise after the unpack-status fix in the previous commit.
send-pack.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/send-pack.c b/send-pack.c index e15232739..d2d2a49a0 100644 --- a/send-pack.c +++ b/send-pack.c @@ -72,6 +72,7 @@ static int pack_objects(int fd, struct ref *refs, struct sha1_array *extra, stru struct child_process po = CHILD_PROCESS_INIT; FILE *po_in; int i; + int rc; i = 4; if (args->use_thin_pack) @@ -125,8 +126,20 @@ static int pack_objects(int fd, struct ref *refs, struct sha1_array *extra, stru po.out = -1; } - if (finish_command(&po)) + rc = finish_command(&po); + if (rc) { + /* + * For a normal non-zero exit, we assume pack-objects wrote + * something useful to stderr. For death by signal, though, + * we should mention it to the user. The exception is SIGPIPE + * (141), because that's a normal occurence if the remote end + * hangs up (and we'll report that by trying to read the unpack + * status). + */ + if (rc > 128 && rc != 141) + error("pack-objects died of signal %d", rc - 128); return -1; + } return 0; }
-- 2.12.0.429.gde83c8049