{"thread":{"id":"21291","subject":"git gc and kernel.org","startedAt":"2009-10-20T07:00:54Z","lastAt":"2009-10-21T22:32:25Z","messageCount":18,"participants":["H. Peter Anvin","Junio C Hamano","Johan Herland","Mikael Magnusson","Nicolas Pitre","Johannes Sixt","Jan Krüger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125449","messageId":"4ADD6026.8070203@zytor.com","threadId":"21291","inReplyTo":null,"subject":"git gc and kernel.org","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-10-20T07:00:54Z","receivedAt":"2009-10-20T07:00:54Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"We have run into two major problems with git on kernel.org. We have \ndiscussed workarounds, but I believe they are generally major problems \nwhich will affect other sites, and really need to be fixed upstream.\n\n1) git receive-pack doesn't run git gc --auto.\n\nThis cause repositories which people thought were being autopacked to \nnot be so. This can be done via a hook, but that is way too painful for \npeople to do -- in fact, it's hard enough just to get people to enable \nthe post-update hook for http fetching.\n\n1b) as per the above, a way to make \"git update-server-info\" at \npost-update time a configurable option rather than needing to be done \nvia the hook would be very nice, since a configuration option can be \nenabled sitewide.\n\n2) When pushing to a repository, it apparently doesn't honor new objects \nin alternate repositories. This causes massive unnecessary duplication.\n\nI believe these are major issues that need to be addressed. If we are \n*mistaken* on these, then we would appreciate being corrected.\n\nThanks,\n\n\t-hpa\n"},{"id":"125452","messageId":"7veioyqzeo.fsf@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"4ADD6026.8070203@zytor.com","subject":"Re: git gc and kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T07:48:15Z","receivedAt":"2009-10-20T07:48:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> We have run into two major problems with git on kernel.org. We have\n> discussed workarounds, but I believe they are generally major problems\n> which will affect other sites, and really need to be fixed upstream.\n>\n> 1) git receive-pack doesn't run git gc --auto.\n>\n> This cause repositories which people thought were being autopacked to\n> not be so. This can be done via a hook, but that is way too painful\n> for people to do -- in fact, it's hard enough just to get people to\n> enable the post-update hook for http fetching.\n>\n> 1b) as per the above, a way to make \"git update-server-info\" at\n> post-update time a configurable option rather than needing to be done\n> via the hook would be very nice, since a configuration option can be\n> enabled sitewide.\n>\n> 2) When pushing to a repository, it apparently doesn't honor new\n> objects in alternate repositories. This causes massive unnecessary\n> duplication.\n>\n> I believe these are major issues that need to be addressed. If we are\n> *mistaken* on these, then we would appreciate being corrected.\n\nI actually was wondering if (2) is still true after reading the message\nfrom Wilcox. It should be a simple matter of testing, but I think this\nissue was improved around the end of January this year with v1.6.1.2.\n\nAs to (1), I think it is reasonable to do some sort of \"gc\" in\nreceive-pack, and while I recall that Linus was violently against the\nidea, I personally think it is reasonable to run update-server-info\nourselves at the same time without needing the hook, even if the\nrepository is never going to be served over dumb http [*1*]. At one\npoint, update-server-info used to compute a lot more than what we\ncurrently compute and it made some sense to oppose against it on\nperformance ground.\n\nBut these days it only lists the refs and packs and does nothing else; the\nperformance impact should be immeasurable and it adds only two files to\nthe repository. It cannot be a big deal, unless you oppose to http\ntransport on a non-technical ground.\n"},{"id":"125453","messageId":"4ADD6BEA.3080300@zytor.com","threadId":"21291","inReplyTo":"7veioyqzeo.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-10-20T07:51:06Z","receivedAt":"2009-10-20T07:51:06Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/20/2009 04:48 PM, Junio C Hamano wrote:\n> As to (1), I think it is reasonable to do some sort of \"gc\" in\n> receive-pack, and while I recall that Linus was violently against the\n> idea, I personally think it is reasonable to run update-server-info\n> ourselves at the same time without needing the hook, even if the\n> repository is never going to be served over dumb http [*1*]. At one\n> point, update-server-info used to compute a lot more than what we\n> currently compute and it made some sense to oppose against it on\n> performance ground.\n>\n> But these days it only lists the refs and packs and does nothing else; the\n> performance impact should be immeasurable and it adds only two files to\n> the repository. It cannot be a big deal, unless you oppose to http\n> transport on a non-technical ground.\n\nI'm obviously happy with making it a non-default option; we can enable \nit sitewide on kernel.org.\n\nHowever, git update-server-info seems to take almost no time even in \nvery large repos.\n\n\t-hpa\n"},{"id":"125455","messageId":"200910201054.48315.johan@herland.net","threadId":"21291","inReplyTo":"7veioyqzeo.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-10-20T08:54:48Z","receivedAt":"2009-10-20T08:54:48Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 20 October 2009, Junio C Hamano wrote:\n> At one point, update-server-info used to compute a lot more than what we\n> currently compute and it made some sense to oppose against it on\n> performance ground.\n> \n> But these days it only lists the refs and packs and does nothing else;\n> the performance impact should be immeasurable and it adds only two files\n> to the repository. It cannot be a big deal, unless you oppose to http\n> transport on a non-technical ground.\n\nFYI, update-server-info takes ~0.7 seconds in a repo with one pack and \n~50000 refs, so I guess it's acceptable to enable it by default, even in \nthose kinds of repos.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"125458","messageId":"237967ef0910200208t290d7ba2l15c75081da5448de@mail.gmail.com","threadId":"21291","inReplyTo":"4ADD6026.8070203@zytor.com","subject":"Re: git gc and kernel.org","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2009-10-20T09:08:34Z","receivedAt":"2009-10-20T09:08:34Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2009/10/20 H. Peter Anvin :\n> We have run into two major problems with git on kernel.org. We have\n> discussed workarounds, but I believe they are generally major problems which\n> will affect other sites, and really need to be fixed upstream.\n>\n> 1) git receive-pack doesn't run git gc --auto.\n>\n> This cause repositories which people thought were being autopacked to not be\n> so. This can be done via a hook, but that is way too painful for people to\n> do -- in fact, it's hard enough just to get people to enable the post-update\n> hook for http fetching.\n>\n> 1b) as per the above, a way to make \"git update-server-info\" at post-update\n> time a configurable option rather than needing to be done via the hook would\n> be very nice, since a configuration option can be enabled sitewide.\n>\n> 2) When pushing to a repository, it apparently doesn't honor new objects in\n> alternate repositories. This causes massive unnecessary duplication.\n>\n> I believe these are major issues that need to be addressed. If we are\n> *mistaken* on these, then we would appreciate being corrected.\n\nI don't know how you create repos on kernel.org, but by default both\ngit init and git clone uses /usr/share/git-core/templates for the new\nrepo, for example I put a symbolic ref h -> HEAD there to save some\ntyping. You can enable whatever hooks you want there, but they would\nonly take effect for new repos.\n\n-- \nMikael Magnusson\n"},{"id":"125522","messageId":"alpine.LFD.2.00.0910201442480.21460@xanadu.home","threadId":"21291","inReplyTo":"200910201054.48315.johan@herland.net","subject":"Re: git gc and kernel.org","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-20T18:46:02Z","receivedAt":"2009-10-20T18:46:02Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 20 Oct 2009, Johan Herland wrote:\n\n> On Tuesday 20 October 2009, Junio C Hamano wrote:\n> > At one point, update-server-info used to compute a lot more than what we\n> > currently compute and it made some sense to oppose against it on\n> > performance ground.\n> > \n> > But these days it only lists the refs and packs and does nothing else;\n> > the performance impact should be immeasurable and it adds only two files\n> > to the repository. It cannot be a big deal, unless you oppose to http\n> > transport on a non-technical ground.\n> \n> FYI, update-server-info takes ~0.7 seconds in a repo with one pack and \n> ~50000 refs, so I guess it's acceptable to enable it by default, even in \n> those kinds of repos.\n\nStill... Hopefully this is going to become redundant information in the \nfuture with the eventual deployment of smart protocol over HTTP. So I \nthink that as a config option being off by default this is a good \ncompromize. Site administrators can turn it on by default in \n/etc/gitconfig.\n\n\nNicolas\n"},{"id":"125529","messageId":"7v63a9n5i6.fsf@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"alpine.LFD.2.00.0910201442480.21460@xanadu.home","subject":"Re: git gc and kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T21:02:25Z","receivedAt":"2009-10-20T21:02:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Still... Hopefully this is going to become redundant information in the \n> future with the eventual deployment of smart protocol over HTTP. So I \n> think that as a config option being off by default this is a good \n> compromize. Site administrators can turn it on by default in \n> /etc/gitconfig.\n\nOk, something like this?\n\n\n Documentation/config.txt | 8 ++++++++\n builtin-receive-pack.c | 18 ++++++++++++++++++\n 2 files changed, 26 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex cd17814..2d3b4f5 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1320,6 +1320,10 @@ rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n \trebase. False by default.\n \n+receive.autogc::\n+\tIf set to true, git-receive-pack will run \"git-gc --auto\"\n+\tafter receiving data from git-push and updating refs.\n+\n receive.fsckObjects::\n \tIf it is set to true, git-receive-pack will check all received\n \tobjects. It will abort in the case of a malformed object or a\n@@ -1355,6 +1359,10 @@ receive.denyNonFastForwards::\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n \n+receive.updateserverinfo::\n+\tIf set to true, git-receive-pack will run git-update-server-info\n+\tafter receiving data from git-push and updating refs.\n+\n remote..url::\n \tThe URL of a remote repository. See linkgit:git-fetch[1] or\n \tlinkgit:git-push[1].\ndiff --git a/builtin-receive-pack.c b/builtin-receive-pack.c\nindex b771fe9..6573226 100644\n--- a/builtin-receive-pack.c\n+++ b/builtin-receive-pack.c\n@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;\n static int unpack_limit = 100;\n static int report_status;\n static int prefer_ofs_delta = 1;\n+static int auto_update_server_info;\n+static int auto_gc;\n static const char *head_name;\n static char *capabilities_to_send;\n \n@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n+\tif (strcmp(var, \"receive.updateserverinfo\") == 0) {\n+\t\tauto_update_server_info = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (strcmp(var, \"receive.autogc\") == 0) {\n+\t\tauto_gc = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \treturn git_default_config(var, value, cb);\n }\n \n@@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)\n \t\t\treport(unpack_status);\n \t\trun_receive_hook(post_receive_hook);\n \t\trun_update_post_hook(commands);\n+\t\tif (auto_update_server_info)\n+\t\t\tupdate_server_info(0);\n+\t\tif (auto_gc) {\n+\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n+\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n+\t\t}\n \t}\n \treturn 0;\n }\n"},{"id":"125531","messageId":"alpine.LFD.2.00.0910201706430.21460@xanadu.home","threadId":"21291","inReplyTo":"7v63a9n5i6.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-20T21:16:34Z","receivedAt":"2009-10-20T21:16:34Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 20 Oct 2009, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > Still... Hopefully this is going to become redundant information in the \n> > future with the eventual deployment of smart protocol over HTTP. So I \n> > think that as a config option being off by default this is a good \n> > compromize. Site administrators can turn it on by default in \n> > /etc/gitconfig.\n> \n> Ok, something like this?\n\nLooks fine to me, except...\n\n> +receive.autogc::\n> +\tIf set to true, git-receive-pack will run \"git-gc --auto\"\n> +\tafter receiving data from git-push and updating refs.\n\nWhile I was arguing for automatic git-update-server-info to be off by \ndefault, I however think that this one might be worth turning on by \ndefault. Most of the time I expect people simply don't log into the \nserver where they push stuff and the kernel.org episode certainly shows \nthis as being a worthwhile thing to do, and contrary to \nupdate-server-info this is likely to always be so even in the future.\n\n> @@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)\n> \t\t\treport(unpack_status);\n> \t\trun_receive_hook(post_receive_hook);\n> \t\trun_update_post_hook(commands);\n> +\t\tif (auto_update_server_info)\n> +\t\t\tupdate_server_info(0);\n> +\t\tif (auto_gc) {\n> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n> +\t\t}\n\nIf git-update-server-info is listing packs, shouldn't it be run after \ngit-gc and not before?\n\n\nNicolas\n"},{"id":"125536","messageId":"7vljj5lofb.fsf_-_@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"alpine.LFD.2.00.0910201706430.21460@xanadu.home","subject":"[PATCH] receive-pack: run \"gc --auto\" and optionally \"update-server-info\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-20T21:56:40Z","receivedAt":"2009-10-20T21:56:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Introduce two new configuration variables, receive.autogc (defaults to\ntrue) and receive.updateserverinfo (defaults to false). When these are\nset, receive-pack runs \"gc --auto\" and \"update-server-info\" respectively\nafter it finishes receiving data from \"git push\" and updating refs.\n\nSigned-off-by: Junio C Hamano \n---\n\n Nicolas Pitre writes:\n\n > On Tue, 20 Oct 2009, Junio C Hamano wrote:\n >\n >> Nicolas Pitre writes:\n >> \n >> > Still... Hopefully this is going to become redundant information in the \n >> > future with the eventual deployment of smart protocol over HTTP. So I \n >> > think that as a config option being off by default this is a good \n >> > compromize. Site administrators can turn it on by default in \n >> > /etc/gitconfig.\n >> \n >> Ok, something like this?\n >\n > Looks fine to me, except...\n\n Everything you said sounded sensible. Thanks.\n\n Documentation/config.txt | 9 +++++++++\n builtin-receive-pack.c | 18 ++++++++++++++++++\n 2 files changed, 27 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex cd17814..ba6ed10 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1320,6 +1320,11 @@ rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n \trebase. False by default.\n \n+receive.autogc::\n+\tBy default, git-receive-pack will run \"git-gc --auto\" after\n+\treceiving data from git-push and updating refs. You can stop\n+\tit by setting this variable to false.\n+\n receive.fsckObjects::\n \tIf it is set to true, git-receive-pack will check all received\n \tobjects. It will abort in the case of a malformed object or a\n@@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n \n+receive.updateserverinfo::\n+\tIf set to true, git-receive-pack will run git-update-server-info\n+\tafter receiving data from git-push and updating refs.\n+\n remote..url::\n \tThe URL of a remote repository. See linkgit:git-fetch[1] or\n \tlinkgit:git-push[1].\ndiff --git a/builtin-receive-pack.c b/builtin-receive-pack.c\nindex b771fe9..92173ac 100644\n--- a/builtin-receive-pack.c\n+++ b/builtin-receive-pack.c\n@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;\n static int unpack_limit = 100;\n static int report_status;\n static int prefer_ofs_delta = 1;\n+static int auto_update_server_info;\n+static int auto_gc = 1;\n static const char *head_name;\n static char *capabilities_to_send;\n \n@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n+\tif (strcmp(var, \"receive.updateserverinfo\") == 0) {\n+\t\tauto_update_server_info = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (strcmp(var, \"receive.autogc\") == 0) {\n+\t\tauto_gc = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \treturn git_default_config(var, value, cb);\n }\n \n@@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)\n \t\t\treport(unpack_status);\n \t\trun_receive_hook(post_receive_hook);\n \t\trun_update_post_hook(commands);\n+\t\tif (auto_gc) {\n+\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n+\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n+\t\t}\n+\t\tif (auto_update_server_info)\n+\t\t\tupdate_server_info(0);\n \t}\n \treturn 0;\n }\n-- \n1.6.5.1.107.gba912\n"},{"id":"125554","messageId":"alpine.LFD.2.00.0910202009560.21460@xanadu.home","threadId":"21291","inReplyTo":"7vljj5lofb.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] receive-pack: run \"gc --auto\" and optionally \"update-server-info\"","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-21T00:21:34Z","receivedAt":"2009-10-21T00:21:34Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 20 Oct 2009, Junio C Hamano wrote:\n\n> Introduce two new configuration variables, receive.autogc (defaults to\n> true) and receive.updateserverinfo (defaults to false). When these are\n> set, receive-pack runs \"gc --auto\" and \"update-server-info\" respectively\n> after it finishes receiving data from \"git push\" and updating refs.\n> \n> Signed-off-by: Junio C Hamano \n\nAcked-by: Nicolas Pitre \n\n> ---\n> \n> Nicolas Pitre writes:\n> \n> > On Tue, 20 Oct 2009, Junio C Hamano wrote:\n> >\n> >> Nicolas Pitre writes:\n> >> \n> >> > Still... Hopefully this is going to become redundant information in the \n> >> > future with the eventual deployment of smart protocol over HTTP. So I \n> >> > think that as a config option being off by default this is a good \n> >> > compromize. Site administrators can turn it on by default in \n> >> > /etc/gitconfig.\n> >> \n> >> Ok, something like this?\n> >\n> > Looks fine to me, except...\n> \n> Everything you said sounded sensible. Thanks.\n> \n> Documentation/config.txt | 9 +++++++++\n> builtin-receive-pack.c | 18 ++++++++++++++++++\n> 2 files changed, 27 insertions(+), 0 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index cd17814..ba6ed10 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1320,6 +1320,11 @@ rebase.stat::\n> \tWhether to show a diffstat of what changed upstream since the last\n> \trebase. False by default.\n> \n> +receive.autogc::\n> +\tBy default, git-receive-pack will run \"git-gc --auto\" after\n> +\treceiving data from git-push and updating refs. You can stop\n> +\tit by setting this variable to false.\n> +\n> receive.fsckObjects::\n> \tIf it is set to true, git-receive-pack will check all received\n> \tobjects. It will abort in the case of a malformed object or a\n> @@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::\n> \teven if that push is forced. This configuration variable is\n> \tset when initializing a shared repository.\n> \n> +receive.updateserverinfo::\n> +\tIf set to true, git-receive-pack will run git-update-server-info\n> +\tafter receiving data from git-push and updating refs.\n> +\n> remote..url::\n> \tThe URL of a remote repository. See linkgit:git-fetch[1] or\n> \tlinkgit:git-push[1].\n> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c\n> index b771fe9..92173ac 100644\n> --- a/builtin-receive-pack.c\n> +++ b/builtin-receive-pack.c\n> @@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;\n> static int unpack_limit = 100;\n> static int report_status;\n> static int prefer_ofs_delta = 1;\n> +static int auto_update_server_info;\n> +static int auto_gc = 1;\n> static const char *head_name;\n> static char *capabilities_to_send;\n> \n> @@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)\n> \t\treturn 0;\n> \t}\n> \n> +\tif (strcmp(var, \"receive.updateserverinfo\") == 0) {\n> +\t\tauto_update_server_info = git_config_bool(var, value);\n> +\t\treturn 0;\n> +\t}\n> +\n> +\tif (strcmp(var, \"receive.autogc\") == 0) {\n> +\t\tauto_gc = git_config_bool(var, value);\n> +\t\treturn 0;\n> +\t}\n> +\n> \treturn git_default_config(var, value, cb);\n> }\n> \n> @@ -672,6 +684,12 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)\n> \t\t\treport(unpack_status);\n> \t\trun_receive_hook(post_receive_hook);\n> \t\trun_update_post_hook(commands);\n> +\t\tif (auto_gc) {\n> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n> +\t\t}\n> +\t\tif (auto_update_server_info)\n> +\t\t\tupdate_server_info(0);\n> \t}\n> \treturn 0;\n> }\n> -- \n> 1.6.5.1.107.gba912\n> \n"},{"id":"125557","messageId":"4ADE5D27.2000907@zytor.com","threadId":"21291","inReplyTo":"237967ef0910200208t290d7ba2l15c75081da5448de@mail.gmail.com","subject":"Re: git gc and kernel.org","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2009-10-21T01:00:23Z","receivedAt":"2009-10-21T01:00:23Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 10/20/2009 06:08 PM, Mikael Magnusson wrote:\n>\n> I don't know how you create repos on kernel.org, but by default both\n> git init and git clone uses /usr/share/git-core/templates for the new\n> repo, for example I put a symbolic ref h -> HEAD there to save some\n> typing. You can enable whatever hooks you want there, but they would\n> only take effect for new repos.\n>\n\nThey only take effect for new repos, and any changes I do there get \nmessed up when git is updated.\n\n\t-hpa\n"},{"id":"125567","messageId":"4ADEA93E.7060907@viscovery.net","threadId":"21291","inReplyTo":"7v63a9n5i6.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-21T06:25:02Z","receivedAt":"2009-10-21T06:25:02Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> +\t\tif (auto_gc) {\n> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n\nAm I correct that this will produce progress output? If git-daemon runs\nreceive-pack, then this output will go to the syslog. Do we care?\n\n-- Hannes\n"},{"id":"125573","messageId":"7vzl7l8b1y.fsf@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"4ADEA93E.7060907@viscovery.net","subject":"Re: git gc and kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T07:23:53Z","receivedAt":"2009-10-21T07:23:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Junio C Hamano schrieb:\n>> +\t\tif (auto_gc) {\n>> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n>> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>\n> Am I correct that this will produce progress output? If git-daemon runs\n> receive-pack, then this output will go to the syslog. Do we care?\n\nWe do, and we don't want that. Thanks for spotting.\n\nWould adding \"--quiet\" to the mix be enough?\n"},{"id":"125574","messageId":"7vaazl8acd.fsf@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"7vzl7l8b1y.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T07:39:14Z","receivedAt":"2009-10-21T07:39:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Sixt writes:\n>\n>> Junio C Hamano schrieb:\n>>> +\t\tif (auto_gc) {\n>>> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n>>> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>\n>> Am I correct that this will produce progress output? If git-daemon runs\n>> receive-pack, then this output will go to the syslog. Do we care?\n>\n> We do, and we don't want that. Thanks for spotting.\n>\n> Would adding \"--quiet\" to the mix be enough?\n\nActually I don't know. This originally came from \"we _could_ add gc and\nupdate-server-info to hundreds of post-receive hooks, but any repository\nhosting site that holds many central repositories will exactly have the\nsame issue, so why not do this internally\", so it may make sense to do\nexactly the same thing as what we do to the output from hooks. What do we\ndo to them now? stdout-to-stderr?\n"},{"id":"125578","messageId":"4ADEC0DB.4000104@viscovery.net","threadId":"21291","inReplyTo":"7vaazl8acd.fsf@alter.siamese.dyndns.org","subject":"Re: git gc and kernel.org","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-21T08:05:47Z","receivedAt":"2009-10-21T08:05:47Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Junio C Hamano writes:\n> \n>> Johannes Sixt writes:\n>>\n>>> Junio C Hamano schrieb:\n>>>> +\t\tif (auto_gc) {\n>>>> +\t\t\tconst char *argv_gc_auto[] = { \"gc\", \"--auto\", NULL };\n>>>> +\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>> Am I correct that this will produce progress output? If git-daemon runs\n>>> receive-pack, then this output will go to the syslog. Do we care?\n>> We do, and we don't want that. Thanks for spotting.\n>>\n>> Would adding \"--quiet\" to the mix be enough?\n> \n> Actually I don't know. This originally came from \"we _could_ add gc and\n> update-server-info to hundreds of post-receive hooks, but any repository\n> hosting site that holds many central repositories will exactly have the\n> same issue, so why not do this internally\", so it may make sense to do\n> exactly the same thing as what we do to the output from hooks. What do we\n> do to them now? stdout-to-stderr?\n\nYes.\n\nI'm slightly in favor of adding \"--quiet\", because even with this option\nwe see some output:\n\n$ git gc --auto --quiet\nAuto packing your repository for optimum performance. You may also\nrun \"git gc\" manually. See \"git help gc\" for more information.\n\nA compromise would be to reduce this message to the first sentence if\n--quiet was given. This way users who push via ssh or locally get a short\nexplanation why \"git push\" does not finish immediately[*]; and git-daemon\nlogs only a one-liner in the syslog, which might be useful, too.\n\n[*] Skipping the hint to \"run git gc manually\" would even be good in this\ncase, because the hint pertains the remote repository, not the one from\nwhich \"git push\" was issued.\n\n-- Hannes\n"},{"id":"125583","messageId":"20091021122102.0793295e@perceptron","threadId":"21291","inReplyTo":"4ADEC0DB.4000104@viscovery.net","subject":"Re: git gc and kernel.org","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2009-10-21T10:21:02Z","receivedAt":"2009-10-21T10:21:02Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Johannes Sixt wrote:\n> $ git gc --auto --quiet\n> Auto packing your repository for optimum performance. You may also\n> run \"git gc\" manually. See \"git help gc\" for more information.\n> [...]\n> [*] Skipping the hint to \"run git gc manually\" would even be good in\n> this case, because the hint pertains the remote repository, not the\n> one from which \"git push\" was issued.\n\nI agree with your suggestions. On the same note, while we're already\nchanging the message, it might make sense to change it to \"Auto packing\nthe repository [...]\".\n\nJan\n"},{"id":"125662","messageId":"7vfx9cz8fo.fsf_-_@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"4ADEC0DB.4000104@viscovery.net","subject":"[PATCH 1/2] gc --auto --quiet: make the notice a bit less verboase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T22:30:35Z","receivedAt":"2009-10-21T22:30:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When \"gc --auto --quiet\" decides there is something to do, it tells the\nuser what it is doing, as it is going to make the user wait for a bit.\n\nBut the message was a bit too long.\n\nSigned-off-by: Junio C Hamano \n---\n\n Johannes Sixt writes:\n\n > I'm slightly in favor of adding \"--quiet\", because even with this option\n > we see some output:\n >\n > $ git gc --auto --quiet\n > Auto packing your repository for optimum performance. You may also\n > run \"git gc\" manually. See \"git help gc\" for more information.\n >\n > A compromise would be to reduce this message to the first sentence if\n > --quiet was given.\n\n builtin-gc.c | 11 +++++++----\n 1 files changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex 7d3e9cc..093517e 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -216,10 +216,13 @@ int cmd_gc(int argc, const char **argv, const char *prefix)\n \t\t */\n \t\tif (!need_to_gc())\n \t\t\treturn 0;\n-\t\tfprintf(stderr, \"Auto packing your repository for optimum \"\n-\t\t\t\"performance. You may also\\n\"\n-\t\t\t\"run \\\"git gc\\\" manually. See \"\n-\t\t\t\"\\\"git help gc\\\" for more information.\\n\");\n+\t\tfprintf(stderr,\n+\t\t\t\"Auto packing the repository for optimum performance.%s\\n\",\n+\t\t\tquiet\n+\t\t\t? \"\"\n+\t\t\t: (\" You may also\\n\"\n+\t\t\t \"run \\\"git gc\\\" manually. See \"\n+\t\t\t \"\\\"git help gc\\\" for more information.\"));\n \t} else\n \t\tappend_option(argv_repack,\n \t\t\t prune_expire && !strcmp(prune_expire, \"now\")\n-- \n1.6.5.1.107.gba912\n"},{"id":"125661","messageId":"7vbpk0z8cm.fsf_-_@alter.siamese.dyndns.org","threadId":"21291","inReplyTo":"4ADEC0DB.4000104@viscovery.net","subject":"[PATCH 2/2] receive-pack: run \"gc --auto --quiet \" and optionally \"update-server-info\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T22:32:25Z","receivedAt":"2009-10-21T22:32:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Introduce two new configuration variables, receive.autogc (defaults to\ntrue) and receive.updateserverinfo (defaults to false). When these are\nset, receive-pack runs \"gc --auto --quiet\" and \"update-server-info\"\nrespectively after it finishes receiving data from \"git push\" and updating\nrefs.\n\nSigned-off-by: Junio C Hamano \nAcked-by: Nicolas Pitre \n---\n * third round; autogc is default (since v2) and runs \"gc --auto\"\n with \"--quiet\" (change in this round).\n\n Documentation/config.txt | 9 +++++++++\n builtin-receive-pack.c | 20 ++++++++++++++++++++\n 2 files changed, 29 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex cd17814..ba6ed10 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1320,6 +1320,11 @@ rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n \trebase. False by default.\n \n+receive.autogc::\n+\tBy default, git-receive-pack will run \"git-gc --auto\" after\n+\treceiving data from git-push and updating refs. You can stop\n+\tit by setting this variable to false.\n+\n receive.fsckObjects::\n \tIf it is set to true, git-receive-pack will check all received\n \tobjects. It will abort in the case of a malformed object or a\n@@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n \n+receive.updateserverinfo::\n+\tIf set to true, git-receive-pack will run git-update-server-info\n+\tafter receiving data from git-push and updating refs.\n+\n remote..url::\n \tThe URL of a remote repository. See linkgit:git-fetch[1] or\n \tlinkgit:git-push[1].\ndiff --git a/builtin-receive-pack.c b/builtin-receive-pack.c\nindex b771fe9..e8bde02 100644\n--- a/builtin-receive-pack.c\n+++ b/builtin-receive-pack.c\n@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;\n static int unpack_limit = 100;\n static int report_status;\n static int prefer_ofs_delta = 1;\n+static int auto_update_server_info;\n+static int auto_gc = 1;\n static const char *head_name;\n static char *capabilities_to_send;\n \n@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n+\tif (strcmp(var, \"receive.updateserverinfo\") == 0) {\n+\t\tauto_update_server_info = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (strcmp(var, \"receive.autogc\") == 0) {\n+\t\tauto_gc = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \treturn git_default_config(var, value, cb);\n }\n \n@@ -672,6 +684,14 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)\n \t\t\treport(unpack_status);\n \t\trun_receive_hook(post_receive_hook);\n \t\trun_update_post_hook(commands);\n+\t\tif (auto_gc) {\n+\t\t\tconst char *argv_gc_auto[] = {\n+\t\t\t\t\"gc\", \"--auto\", \"--quiet\", NULL,\n+\t\t\t};\n+\t\t\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n+\t\t}\n+\t\tif (auto_update_server_info)\n+\t\t\tupdate_server_info(0);\n \t}\n \treturn 0;\n }\n-- \n1.6.5.1.107.gba912\n"}]}