Re: pack count on repo.or.cz [was "Medium term dreams"]

From: Jeff King <peff@peff.net>
Date: Sep 2, 2008, 11:54 UTC
Message-ID: <20080902115424.GA11303@coredump.intra.peff.net>
In-Reply-To: <20080902111531.GL10360@machine.or.cz>

On Tue, Sep 02, 2008 at 01:15:31PM +0200, Petr Baudis wrote:

Show 13 quoted lines

> > Hmm, I thought that was the point of adding the "-A" flag to git-repack.
> 
> Ok, I did
> 
> 	git repack -A -d
> 
> in repo.or.cz's git.git. What next? I have brand-new
>
> 	-rw-rw-r-- 1 root root  1314056 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.idx
> 	-rw-rw-r-- 1 root root 17344999 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.pack
> 
> but all the old packs too; git repack didn't delete anything,
> git prune-packed seems to have no effect either.

Hmm. Certainly the new pack is as expected. And you may also have some new loose objects. It's easier to see what's going on with:

  mkdir repo && cd repo
  git init
  git config core.logallrefupdates false
  echo content >file && git add file && git commit -m one
  echo changes >>file && git commit -a -m two
  git repack -a -d

at this point we have the one pack:

  $ find .git/objects -type f
  .git/objects/pack/pack-ba174ac1cf22ba99a92878c562483321baa93d38.pack
  .git/objects/pack/pack-ba174ac1cf22ba99a92878c562483321baa93d38.idx
  .git/objects/info/packs

and then we lose the reference and pack again:

  git reset --hard HEAD^
  git repack -A -d

and now we have our single-commit pack, with a few loose objects from the other commit:

  $ find .git/objects -type f
  .git/objects/13/cb02d81aac9cedca2700fb56aeddeb984dc57b
  .git/objects/78/a66295f2d04f2dd4ea90b4b99a6de73ea4ac12
  .git/objects/fe/79de90b5f7d6d4b23dc858f861834e2a76af7b
  .git/objects/info/packs
  .git/objects/pack/pack-c9a76fe2b061890a18396b70ec3d6a638383046e.idx
  .git/objects/pack/pack-c9a76fe2b061890a18396b70ec3d6a638383046e.pack

So did you check for loose objects? That is what you should get if there were any objects that would have been lost. If there aren't any new loose objects, then there were no objects that would be lost.

As to why the other packs weren't pruned, I don't know. In my example, you can see that the pruning happens as we expect. So either there is a bug in git-prune-packed, or there is something we're not realizing.

> So not just refs but also alternates? What if someone accesses the
> reposiory at that moment? I would also need to make the symlinks quite
> densely to avoid refs/forkee/-induced loops.

I think you could probably do it safely with a symlink farm (and I sort of assumed you were doing something like that already for pruning, but perhaps you are just not pruning at all).

> I might as well just use a common repository for all the forks then. But
> this does not scale at all for dumb transports, does it?

It depends how different the forks are. :) But I think it is better if we can avoid that.

-Peff