Re: git gc and kernel.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"H. Peter Anvin" <hpa@xxxxxxxxx> 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.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]