On Tue, 11 Sep 2007, Andreas Ericsson wrote: > Andreas Ericsson wrote: > > Nicolas Pitre wrote: > > > On Tue, 11 Sep 2007, Andreas Ericsson wrote: > > > > > > > So how does one unpack a packfile to extract the loose objects? > > > > > > > > mv .git/objects/pack/*.pack /tmp/git-packs > > > > for p in /tmp/git-packs/*.pack; do git unpack-objects < $p; done > > > > > > > > ? > > > > > > > > Seems like an awful lot of trouble. I'll look into patching > > > > builtin-pack-objects.c instead to accept an "--ignore-reflog" flag and > > > > prune > > > > reflog-accessible objects. Will that break anything fundamental? > > > > > > Why would you want to extract loose objects in the first place? That > > > appears to be a really funny goal to me. > > > > > > > I didn't. I wanted to get rid of superfluous loose objects in the odb. > > > > I'll expand on this a bit. > > I thought that the loose tips weren't being pruned because they were packed. > I had forgotten about the reflog protecting them from deletion, so in order > to get rid of the loose tips after I was done getting my data back, I wanted > to prune all the objects. Since I believed that would require all the objects > to be loose, I sought to unpack the packs I had created. > > I realize now that unpack-objects *must* work as Junio explained in another > email (ie, not unpack anything that's already in the odb), as unpack-objects > is used to explode the packs received when pulling (or being pushed to). > Should it have different semantics, git users would otherwise risk having > known good objects clobbered by bad ones via some social engineering and a > pull from a malign repo. Note that if you truly want to get rid of unreferenced objects, you simply have to run 'git gc' or 'git repack -a -d'. The unreferenced objects will vanish, even if they were already packed previously. The new pack will simply not contain them anymore. Nicolas - 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
