Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: git gc and kernel.org

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:47:35

Junio C Hamano schrieb:
Junio C Hamano [off-list ref] writes:
quoted
Johannes Sixt [off-list ref] writes:
quoted
Junio C Hamano schrieb:
quoted
+		if (auto_gc) {
+			const char *argv_gc_auto[] = { "gc", "--auto", NULL };
+			run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
Am I correct that this will produce progress output? If git-daemon runs
receive-pack, then this output will go to the syslog. Do we care?
We do, and we don't want that.  Thanks for spotting.

Would adding "--quiet" to the mix be enough?
Actually I don't know.  This originally came from "we _could_ add gc and
update-server-info to hundreds of post-receive hooks, but any repository
hosting site that holds many central repositories will exactly have the
same issue, so why not do this internally", so it may make sense to do
exactly the same thing as what we do to the output from hooks.  What do we
do to them now?  stdout-to-stderr?
Yes.

I'm slightly in favor of adding "--quiet", because even with this option
we see some output:

$ git gc --auto --quiet
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.

A compromise would be to reduce this message to the first sentence if
--quiet was given. This way users who push via ssh or locally get a short
explanation why "git push" does not finish immediately[*]; and git-daemon
logs only a one-liner in the syslog, which might be useful, too.

[*] Skipping the hint to "run git gc manually" would even be good in this
case, because the hint pertains the remote repository, not the one from
which "git push" was issued.

-- Hannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help