"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.
On 10/20/2009 04:48 PM, Junio C Hamano wrote:
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.
I'm obviously happy with making it a non-default option; we can enable
it sitewide on kernel.org.
However, git update-server-info seems to take almost no time even in
very large repos.
-hpa
On Tuesday 20 October 2009, Junio C Hamano wrote:
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.
FYI, update-server-info takes ~0.7 seconds in a repo with one pack and
~50000 refs, so I guess it's acceptable to enable it by default, even in
those kinds of repos.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
On Tue, 20 Oct 2009, Johan Herland wrote:
On Tuesday 20 October 2009, Junio C Hamano wrote:
quoted
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.
FYI, update-server-info takes ~0.7 seconds in a repo with one pack and
~50000 refs, so I guess it's acceptable to enable it by default, even in
those kinds of repos.
Still... Hopefully this is going to become redundant information in the
future with the eventual deployment of smart protocol over HTTP. So I
think that as a config option being off by default this is a good
compromize. Site administrators can turn it on by default in
/etc/gitconfig.
Nicolas