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

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

quoted

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