From: Junio C Hamano Date: Sat, 25 Aug 2007 00:04:55 GMT Subject: Re: git-daemon on NSLU2 Message-ID: <7v1wdscwd4.fsf@gitster.siamese.dyndns.org> In-Reply-To: <9e4733910708241646x7b285574t94c3d7eb32bb60c9@mail.gmail.com> "Jon Smirl" writes: > On 8/24/07, Jakub Narebski 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. 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 your client "clone"s only a single branch by doing: $ git init $ git remote add origin $remote_url $ git pull origin master the set of objects you need to send would be different (slightly smaller) than the normal clone. - Another example would be a client that uses --reference: $ git clone --reference neigh.git git://yourbox/repo.git which would give you a request that is different from the usual initial full clone request.