On Thu, Apr 16, 2020 at 08:34:27PM +0200, Johannes Sixt wrote: > > This is usually handled by the gc expiration time, which is compared > > against the file mtime. The default is 2 weeks, but even something short > > like 5 minutes would be plenty to avoid this race (even for a long > > import, we should be updating the mtime every time we call write()). > > Except that on Windows the times are only updated reliably when all file > handles refering to the file are closed. Would that poke a hole in your > argument? (I don't think so, as long as expiration times are not > ridiculously short; and people who do gc --prune=now should know what > they are doing -- and when.) Yes, if you do "git gc --prune=5.minutes" while an hour-long fast-import is running, you might be in trouble. Don't do that. Though on _any_ system, there are other cases where objects sit untouched before being referenced. I guess we pull from the index for reachability, so "git add" is safe for blobs. I don't know if we are clever enough to use cache-tree (and it might not even be there), so possibly those trees are at risk until you run "git commit" (or even after you run while waiting in the editor). Certainly I think the whole pruning system is a patchwork of assumptions that could be violated in extreme cases. But it has been that way for 15 years. If people aren't routinely finding objects pruned out from under them, I'm not inclined to spend a lot of time digging on it. -Peff
