On Tue, 12 Jun 2012, Jeff King wrote: > On Mon, Jun 11, 2012 at 08:41:03PM -0400, Nicolas Pitre wrote: > > > > On Mon, Jun 11, 2012 at 06:14:39PM -0400, Ted Ts'o wrote: > > > > > > > One last thought: if a sysadmin is really hard up for space, (and if > > > > the cruft objects include some really big sound or video files) one > > > > advantage of labelling the cruft packs explicitly is that someone who > > > > really needs the space could potentially find the oldest cruft files > > > > and delete them, since they would be tagged for easy findability. > > > > > > No! That's exactly what I was worried about with the name. It is _not_ > > > safe to do so. It's only safe after you have done a full repack to > > > rescue any non-cruft objects. > > > > To make it "safe", the cruft packs would have to be searchable for > > object retrieval, but not during object creation. That nuance would > > affect the core code in subtle ways and I'm not sure if that would be > > worth it ... just for the safe handling of cruft. > > Why is that? If you do a "repack -Ad", then any referenced objects will > have been retrieved and put into the new all-in-one pack. At that point, > by deleting the cruft pack, you are guaranteed to be deleting only > objects that are either unreferenced, or are duplicated in another pack. Now what if you fetch and a bunch of objects are already found in your cruft pack? Right now, we search for the existence of any object before creating them, and if the cruft packs are searchable then such objects won't get uncruftified. 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