From: Jeff King <peff@peff.net>
To: Brandon Casey <drafnel@gmail.com>
Cc: gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH 2/2] prune.c: only print informational message in show_only or verbose mode
Date: Tue, 7 Aug 2012 01:32:25 -0400 [thread overview]
Message-ID: <20120807053225.GA1541@sigill.intra.peff.net> (raw)
In-Reply-To: <1344315709-15897-2-git-send-email-drafnel@gmail.com>
On Mon, Aug 06, 2012 at 10:01:49PM -0700, Brandon Casey wrote:
> This informational message can cause a problem if 'git prune' is spawned
> from an auto-gc during receive-pack. In this case, the informational
> message will be sent back over the wire to the git client and the client
> will try to interpret it as part of the pack protocol and will produce an
> error.
>
> So let's refrain from producing this message unless show_only or verbose
> is enabled.
This seems like a band-aid. The real problem is that auto-gc can
interfere with the pack protocol, which it should not be allowed to do,
no matter what it produces.
We could fix that root cause with this patch (on top of your 1/2):
-- >8 --
Subject: [PATCH] receive-pack: redirect auto-gc stdout to stderr
In some cases, git-gc may produce informational messages to
stdout, rather than stderr. This is bad for receive-pack,
because its stdout (and therefore that of its child) is
connected to a git client and speaking pack protocol.
Instead, let's redirect these messages to stderr to avoid
interference and let the client see them.
Signed-off-by: Jeff King <peff@peff.net>
---
We already do the same thing for all of the hooks we run. With this
change, all sub-processes have their stdout redirected (either to a
pipe, or to stderr) except git-unpack-objects.
Looking at unpack-objects, it should not write anything to stdout under
normal circumstances. However, if it is fed more bytes than the
pack data claims (e.g., extra entries beyond what the header claims), it
will send them to stdout. I've never heard of that happening, but
probably it should go to /dev/null, and/or flag an error.
builtin/receive-pack.c | 3 ++-
t/t5400-send-pack.sh | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 0afb8b2..e0b9f2e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -977,7 +977,8 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
const char *argv_gc_auto[] = {
"gc", "--auto", "--quiet", NULL,
};
- run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ run_command_v_opt(argv_gc_auto,
+ RUN_GIT_CMD | RUN_COMMAND_STDOUT_TO_STDERR);
}
if (auto_update_server_info)
update_server_info(0);
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 04a8791..250c720 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -145,7 +145,7 @@ test_expect_success 'push --all excludes remote-tracking hierarchy' '
)
'
-test_expect_failure 'receive-pack runs auto-gc in remote repo' '
+test_expect_success 'receive-pack runs auto-gc in remote repo' '
rm -rf parent child &&
git init parent &&
(
--
1.7.12.rc1.12.g6d3a2d7
prev parent reply other threads:[~2012-08-07 5:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 1:55 Did we break receive-pack recently? Junio C Hamano
2012-08-06 1:37 ` Brandon Casey
2012-08-06 3:32 ` Brandon Casey
2012-08-07 5:01 ` [PATCH 1/2] t/t5400: demonstrate breakage caused by informational message from prune Brandon Casey
2012-08-07 5:01 ` [PATCH 2/2] prune.c: only print informational message in show_only or verbose mode Brandon Casey
2012-08-07 5:28 ` Junio C Hamano
2012-08-07 5:34 ` Junio C Hamano
2012-08-07 5:44 ` Brandon Casey
2012-08-07 6:03 ` Jeff King
2012-08-07 6:33 ` Brandon Casey
2012-08-07 15:41 ` Junio C Hamano
2012-08-07 21:44 ` Junio C Hamano
2012-08-07 21:59 ` Jeff King
2012-08-07 22:55 ` Brandon Casey
2012-08-07 5:32 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120807053225.GA1541@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).