On Tue, 11 Sep 2007, Andreas Ericsson wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html