Junio C Hamano <gitster@xxxxxxxxx> writes: > "Jon Smirl" <jonsmirl@xxxxxxxxx> writes: > >> On 8/24/07, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >>> 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 - 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
