On Sat, Jun 18, 2016 at 08:58:03PM -0700, Junio C Hamano wrote: > Eric Wong <e@xxxxxxxxx> writes: > > > Avoid pruning files which were written after the prune process > > starts, as it possible to concurrently create new objects while > > "git prune" is running. > > > > Tested on git.git by starting "git prune" in one terminal, > > creating a random loose object via "git hash-object --stdin -w" > > in a different terminal, and ensuring the loose object remains > > after "git prune" completes. > > > > Signed-off-by: Eric Wong <e@xxxxxxxxx> > > --- > > I'm somewhat surprised this check didn't already exist; > > but maybe nobody else runs prune manually, anymore. > > The only time an end user would run "git prune" in their > repositories with working trees these days is "git repack" followed > by "git prune", I would guess. > > The current behaviour is totally expected and that is why you do not > run "prune" without any grace period in an active repository. > > Adding the proposed change however would not make anything worse, I > would think. Those who run "git prune" without grace period accept > that the repository must be quiescent or otherwise the newly created > objects will be lost. So they are unlikely to be doing anything to > create such objects, hence "things newer than 'start'" are unlikely > to appear, and their expectation that "repack && prune" will remove > all loose objects will not be broken. I agree it does not making anything worse from a correctness standpoint, but I am mildly negative in that it adds complexity without any real safety. Even after this patch, running git prune without a grace period isn't safe, as you are racing simultaneous processes that started before prune, or started after prune but before it marks the "start" timestamp. I know it isn't much code, but it makes things harder to reason about. I think it also runs contrary to the logic in 3d27b9b (date.c: add parse_expiry_date(), 2013-04-17)[1]. -Peff [1] More context in http://mid.gmane.org/7vbo9ceqb3.fsf@xxxxxxxxxxxxxxxxxxxxxxxx and the surrounding thread. -- 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