Hi, On Mon, Jul 16, 2018 at 12:19 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Elijah Newren wrote: > >> The basic problem here, at least for us, is that gc has enough >> information to know it could expunge some objects, but because of how >> it is structured in terms of several substeps (reflog expiration, >> repack, prune), the information is lost between the steps and it >> instead writes them out as unreachable objects. If we could prune (or >> avoid exploding) loose objects that are only reachable from reflog >> entries that we are expiring, then the problem goes away for us. > > My understanding is that exploding the objects is intentional behavior, > to avoid a race where objects are newly referenced while they are being > pruned. > > I am not a fan of that behavior. It's still racy. But when we've > brought it up in the past, the consensus seems to have been that it's > better than nothing. Documentation/technical/hash-function-transition.txt > section "Loose objects and unreachable objects" describes a way to > eliminate the race.
Ah, that's good to know and at least makes sense. It seems somewhat odd, though; loose objects that are two weeks old are just as susceptible to being referenced anew by new commits, so the default of running 'git prune --expire=2.weeks.ago' as gc currently does would also be unsafe, wouldn't it? Why is that any more or less unsafe than pruning objects only referenced by reflog entries that are more than 90 days old? Elijah
