Re: pack count on repo.or.cz

Jeff King [off-list ref] writes:

Though an even simpler solution, since you control all of the repos, is
to just temporarily add references from the "parent" of the fork to
every ref of every forked child. Then do the repack in the parent, which
should then contain all of the objects for all of the children, delete
the temporary references, and prune in the children (who should see most
of their objects now in the parent).

Hmm, I am slightly worried about doing so might defeat the whole point of
making the sample repository a separate one from git.git hosted there.

The reason it is not a branch in git.git is because I did not want to
contaminate the official git.git repository with commit objects in tree
objects (aka gitlinks); it would deny access to clients older than 1.5.2.

On Mon, Sep 01, 2008 at 06:47:36PM -0700, Junio C Hamano wrote:

Hmm, I am slightly worried about doing so might defeat the whole point of
making the sample repository a separate one from git.git hosted there.

The reason it is not a branch in git.git is because I did not want to
contaminate the official git.git repository with commit objects in tree
objects (aka gitlinks); it would deny access to clients older than 1.5.2.

Hrm. I had assumed they wouldn't be a problem because nothing actually
_referenced_ them, but I suppose it would break git-fsck on such
systems.

Anyway, I think "git repack -A" is a better solution (and presumably
there is some magic on the pruning end to make sure forks do the right
thing with loose objects).

-Peff