Re: Keeping unreachable objects in a separate pack instead of loose?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 12 Jun 2012, Jeff King wrote:

> On Tue, Jun 12, 2012 at 01:30:07PM -0400, Nicolas Pitre wrote:
> 
> > > > 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.
> 
> Then those objects will remain in the cruft pack. Which is why, as I
> said, it is not generally safe to just delete a cruft pack.

... and my reply was about the needed changes to still make cruft packs 
always crufty even if some of its content suddenly becomes useful again.

> However, when you do a full repack, those objects will be copied into 
> the new pack (because they are referenced). Which is why I am claiming 
> that it is safe to remove cruft packs at that point.

Yes, but then there is no point marking such packs as cruft if at any 
moment they can become useful again.


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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]