Re: git gc and kernel.org

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2009, 07:48 UTC
Message-ID: <7veioyqzeo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4ADD6026.8070203@zytor.com>

"H. Peter Anvin" <hpa@zytor.com> writes:

Show 22 quoted lines

> 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.