Hi all,

I already posted this question in the git users groups
but was advised to better ask the experts in this list. So here we go:

The question is regarding the packs and the repacking of those during
cloning. I'm migrating a big repository which after initial commit of
all files contains only one pack file of 120MB in size (about 800

On this big repo I created various subtree branches (using git subtree
split) so I can clone some of the folders individually (without
getting the whole big thing). The problem is, however, that all my
subtree branch clones seem to get a copy of the big 120MB pack (where
often only 2MB will be extracted from it).

After testing a little bit I figured that this only happens if I use
ssh or the git protocol to clone the repo. When using file:// to
specify the remote repository some repacking seems to happen
automatically and I end up with a new pack file for my clone that only
contains the stuff that is really needed for my branch (which
obviously results in much smaller size).

Running the following commands on the clone created via ssh or git
helps removing the unnecessary overhead and repacks my repo creating a
small pack, discarding the unneded stuff:

git pack-refs --prune
git reflog expire --all
git repack -a -d -f -l

So although that helps me getting a small clone via ssh I have some
questions / doubts:

1. Is it "as designed" that the repacking only happens automatically
when cloning using the file url or could it be a bug that it is not
supported for ssh and git native protocol?
2. Is there already a way to achieve the repacking when cloning using
ssh or git protocol (as obviously I'd prefer to use those over file://
3. Can I provide multiple pre-made packs for my different subtree
branches already on server side to make the cloning even faster and
avoid always having to repack when someone clones a subtree branch?

Thanks a lot,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to