On Tue, Jun 12, 2012 at 03:39:05PM -0400, Nicolas Pitre wrote: > > So the race window depends on the time it takes "git prune" to run. > > > > I wonder if git-prune could do a double-check of the refs. Something > > like: > > > > 1. calculate reachability on all refs > > > > 2. read list of objects to prune, and make a list of unreachable ones > > > > 3. calculate reachability again (which should be very cheap, because > > you can stop when you get to an object you have already seen) > > > > 4. Drop any objects found in (3) from the list in (2), and delete > > items from your list > > > > But I think that still has a race where objects are created before > > step 2, but are not actually referenced until after step 3. I think > > doing it safely may actually require a repo-wide prune lock. > > Yeah... that's what I was thinking too. Maybe we're making our life > overly miserable by trying to avoid any locking here. I think I would be OK with "prune" locking, as long as everything else was able to happen simultaneously. Especially if we can keep prune's lock as short as possible through double-reads or similar tricks (like we do for ref updates). -Peff -- 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