Re: git gc and kernel.org

"H. Peter Anvin" [off-list ref] writes:

We have run into two major problems with git on kernel.org.  We have
discussed workarounds, but I believe they are generally major problems
which will affect other sites, and really need to be fixed upstream.

1) git receive-pack doesn't run git gc --auto.

This cause repositories which people thought were being autopacked to
not be so.  This can be done via a hook, but that is way too painful
for people to do -- in fact, it's hard enough just to get people to
enable the post-update hook for http fetching.

1b) as per the above, a way to make "git update-server-info" at
post-update time a configurable option rather than needing to be done
via the hook would be very nice, since a configuration option can be
enabled sitewide.

2) When pushing to a repository, it apparently doesn't honor new
objects in alternate repositories.  This causes massive unnecessary
duplication.

I believe these are major issues that need to be addressed.  If we are
*mistaken* on these, then we would appreciate being corrected.

I actually was wondering if (2) is still true after reading the message
from Wilcox.  It should be a simple matter of testing, but I think this
issue was improved around the end of January this year with v1.6.1.2.

As to (1), I think it is reasonable to do some sort of "gc" in
receive-pack, and while I recall that Linus was violently against the
idea, I personally think it is reasonable to run update-server-info
ourselves at the same time without needing the hook, even if the
repository is never going to be served over dumb http [*1*].  At one
point, update-server-info used to compute a lot more than what we
currently compute and it made some sense to oppose against it on
performance ground.

But these days it only lists the refs and packs and does nothing else; the
performance impact should be immeasurable and it adds only two files to
the repository.  It cannot be a big deal, unless you oppose to http
transport on a non-technical ground.