Junio C Hamano wrote: > I am a bit hesitant to dismiss with "It's not the right model", as > the original of accessing the repository from two terminals while > one clearly is being accessed busily by gc falls into the same > category. As to why I think it makes sense: garbage collecting unreferenced objects has nothing to do with updating refs, or checking out a worktree. Think about my earlier "make push.default = current resolve HEAD early"; why would the user want to update the ref that is being pushed? She'd most likely want to continue working on another feature on some other branch, and that's perfectly fine. In long-running runtimes, garbage collection is absolutely essential to the performance. Often, stupidly written garbage collectors that stop-the-world (the execution of the program), compact the memory after collection, and then restart the program, can cause the user to throw that runtime out the window (Emacs has a really stupid one, by the way). Most modern runtimes have concurrent garbage collectors that are allocated very fine-grained slots by the scheduler: so, the program won't suddenly come to a grinding halt to do garbage collection. The reason it's so hard to do concurrent gc is because there can be races between data modification via variables (main program), and data being moved around in memory for compacting (gc). Having said all this, the problem is highly simplified in git, because the object store is a const-store. A particular key (sha-1) is guaranteed never to point to the wrong data. Frankly, even if there is concurrent access to the object store, the worst thing that can happen is that the gc didn't collect some dangling objects that were created during the gc run. Unless you have some irrational fear of introducing some unexpected behavior in some convoluted corner case, I really don't see what the problem is. I'm sure server-side implementations have to do it all the time: GitHub and Gerrit certainly doesn't say "I'm gc'ing; please pull after 10 mins". Perhaps they're more conservative than the client side about gc (space is cheap), but that's just a sane default. > It can very well be two terminals, one on one machine each, both > with the same human end-user interaction. Someone does an SSH my machine to a submarine in Russia over a slow connection. I remove an ordinary file, while she's trying to write to it. When did anyone make any guarantees about no races? What does git gc specifically have to do with this? For the record, you can easily mess up your worktree by running two different worktree updates (checkout/ merge) on two different terminals: nothing forbidding it. I don't see how _not_ forbidding gc on two different terminals is better than forbidding it. This is quite an obscure feature for few super-impatient people, and we haven't even advertised it in any documentation. Unless you can present an alternative now (patch-form, please), I think you're being irrationally conservative about this. -- 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