On Sat, May 24, 2014 at 4:40 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy, 9f673f94 (gc: config option for running --auto in background, > 2014-02-08) turns to be not such a hot idea. Sure, if we kick it > off background after doing something heavy, immediately before > giving control back to the end-user, and expect that the user will > stay thinking without making new changes (i.e. read-only stuff like > "git show" would be OK), then daemonize might be a great thing, but > we forgot, while doing that commit, that long-running operations > trigger the auto gc in the middle *and* they want it finish before > they continue, as the purpose of gc is to help the performance > during their further operation. If by "long-running operations" you mean in a single process, it's my first thought too but it looks like autogc is always called when the process is all done and about to exit. The "git pull" case is different because there's rebase after fetch. I see no easy way to detect this kind of "middle of operation". So we have two options: scripts should disable autogc before doing things, a env variable would be more convenient than temporarily updating gc.auto. Or we move "pack-refs" and "reflog expire" up, before turning gc into a background task. Any locking will be serialized this way. We could even go further to keep all but "repack" in the background because it's "repack" that takes the longest time (maybe "prune" coming close to second). -- Duy -- 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