"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.
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.
-
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
