git/send-pack.c, branch v2.12.2

send-pack: report signal death of pack-objects

2017-03-07T22:58:36Z

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 Signed-off-by: Junio C Hamano

send-pack: read "unpack" status even on pack-objects failure

2017-03-07T22:57:39Z

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 Signed-off-by: Junio C Hamano

send-pack: improve unpack-status error messages

2017-03-07T22:54:48Z

When the remote tells us that the "unpack" step failed, we show an error message. However, unless you are familiar with the internals of send-pack and receive-pack, it was not clear that this represented an error on the remote side. Let's re-word to make that more obvious. Likewise, when we got an unexpected packet from the other end, we complained with a vague message but did not actually show the packet. Let's fix that. And finally, neither message was marked for translation. The message from the remote probably won't be translated, but there's no reason we can't do better for the local half. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

send-pack: use skip_prefix for parsing unpack status

2017-03-07T22:54:14Z

This avoids repeating ourselves, and the use of magic numbers. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

send-pack: extract parsing of "unpack" response

2017-03-07T22:51:20Z

After sending the pack, we call receive_status() which gets both the "unpack" line and the ref status. Let's break these into two functions so we can call the first part independently. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

cocci: refactor common patterns to use xstrdup_or_null()

2016-10-12T18:22:10Z

d64ea0f83b ("git-compat-util: add xstrdup_or_null helper", 2015-01-12) added a handy wrapper that allows us to get a duplicate of a string or NULL if the original is NULL, but a handful of codepath predate its introduction or just weren't aware of it. Signed-off-by: Junio C Hamano

Merge branch 'rs/use-strbuf-addstr'

2016-08-08T21:48:41Z

* rs/use-strbuf-addstr: use strbuf_addstr() instead of strbuf_addf() with "%s" use strbuf_addstr() for adding constant strings to a strbuf

use strbuf_addstr() for adding constant strings to a strbuf

2016-08-01T20:42:10Z

Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. In http-push.c it becomes easier to see what's going on without having to verfiy that the definition of PROPFIND_ALL_REQUEST doesn't contain any format specifiers. Signed-off-by: Rene Scharfe Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

push: accept push options

2016-07-14T22:50:41Z

This implements everything that is required on the client side to make use of push options from the porcelain push command. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

send-pack: use buffered I/O to talk to pack-objects

2016-06-08T23:02:40Z

We start a pack-objects process and then write all of the positive and negative sha1s to it over a pipe. We do so by formatting each item into a fixed-size buffer and then writing each individually. This has two drawbacks: 1. There's some manual computation of the buffer size, which is not immediately obvious is correct (though it is). 2. We write() once per sha1, which means a lot more system calls than are necessary. We can solve both by wrapping the pipe descriptor in a stdio handle; this is the same technique used by upload-pack when serving fetches. Note that we can also simplify and improve the error handling here. The original detected a single write error and broke out of the loop (presumably to avoid writing the error message over and over), but never actually acted on seeing an error; we just fed truncated input and took whatever pack-objects returned. In practice, this probably didn't matter, as the likely errors would be caused by pack-objects dying (and we'd probably just die with SIGPIPE anyway). But we can easily make this simpler and more robust; the stdio handle keeps an error flag, which we can check at the end. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano