Thanks.
This patch may fix the immediate symptom, but I think the right fix
is to correct the way "gc" is invoked by receive-pack, so that
nothing "gc" writes to its standard output can leak to the standard
output of the receive-pack. After all, receive-pack is the one that
knows that its output is a structured protocol communication channel
and should not be contaminated by random crufts. Receive-pack is
the one that is responsible to avoid this kind of problem in the
first place.
Once that fix is done, any future changes to "gc" or its subprograms
won't be able to cause the same breakage again. Which automatically
makes your patch unnecessary.
Something along this line, perhaps.
Note that this chooses to expose what comes out of the standard
output of the subprocess to the standard error to be shown to the
user sitting on the other end. This is in line with what we do to
all of our hooks (Cf. cd83c74 (Redirect update hook stdout to
stderr., 2006-12-30)).
If we instead want to discard the standard output, we would need to
either extend run_command_v_opt(), or set up our own child_process
and spawn the subprocess using the underlying run_command() API
ourselves.
builtin/receive-pack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ee7751a..19bdc66 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -979,7 +979,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);
+ int opt = RUN_GIT_CMD | RUN_COMMAND_STDOUT_TO_STDERR;
+ run_command_v_opt(argv_gc_auto, opt);
}
if (auto_update_server_info)
update_server_info(0);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html