Re: [RFC] git-pack-refs --prune

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

 




On Mon, 18 Sep 2006, Junio C Hamano wrote:
> 
> I am not sure I got the locking right, hence this RFC.

It looks correct (the important part to check is that the SHA1 of the ref 
you remove still matches the SHA1 of the object you packed).

That said, we should fix it up a bit, notably

 - we should _not_ prune refs that are indirect.

   Right now, if we have a symbolic link, we _incorrectly_ pack it as 
   unlinked. The packed format doesn't have any "link" format.

   This isn't a problem in practice, because the only link we ever use is 
   the HEAD link, but it's incorrect. As long as we don't prune, it wasn't 
   an issue - a unpacked head will always override a packed one, so 
   packing the thing didn't really matter.

 - we should probably avoid even trying to prune stuff that was already 
   packed.

The way to fix both these problems at once would be to add a flag to the 
"for_each_ref()", which says whether it followed a link, or whether it was 
already packed, so that we wouldn't pack symlinks at all, and we wouldn't 
add already-packed refs to the "keeprefs" list.

But that requires a sligh semantic extension to "do_for_each_ref()" (and 
"struct ref_list" needs a flag to say whether it was looked up through a 
symlink).

I was thinking that the easy way to solve it is to just _pack_ everything 
(the way we do now - incorrectly for symrefs), but never prune a symref.

		Linus
-
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]