On Tue, Sep 02, 2008 at 01:15:31PM +0200, Petr Baudis wrote: > > 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 -- 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
