Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:54:03

On Tue, Jun 12, 2012 at 03:39:05PM -0400, Nicolas Pitre wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help