Thread (1 message) 1 message, 1 author, 2016-06-15

Re: git-daemon on NSLU2

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:30

Junio C Hamano [off-list ref] writes:
"Jon Smirl" [off-list ref] writes:
quoted
On 8/24/07, Jakub Narebski [off-list ref] wrote:
quoted
There was idea to special case clone (just concatenate the packs, the
receiving side as someone told there can detect pack boundaries; do not
forget to pack loose objects, first), instead of using generic fetch --all
for clone, bnut no code. Code speaks louder than words (although if someone
would provide details of pack boundary detection...)
A related concept, initial clone of a repository does the equivalent
of repack -a on the repo before transmitting it. Why aren't we saving
those results by switching the repo onto the new pack file? Then the
next clone that comes along won't have to do anything but send the
file.
If the majority of the access to your repository is the initial
clone request, then it might be a worthwhile thing to do.  In fact
didn't we use to have such a "pre-prepared pack" support?

But I do not think "majority is initial clone" is the norm.
Well, as long as the majority is not affected negatively, catering for
a minority better is a strict improvement.  Most repositories will
never get cloned and won't be affected.  But there are some
repositories with a non-trivial amount of cloning.
Even among the people who does an "initial clone" (from the
end-user perspective), what they do may not be the initial full
clone your special hack helps (and that was one of the reasons
we dropped the pre-prepared pack support --- "been there, done
that" to some extent).
If it doesn't get used, its presence does no harm, of course except
from having to be maintained and tested.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help