Adam Borowski <kilobyte@xxxxxxxxxx> writes: > On Fri, May 23, 2014 at 02:40:41PM -0700, Junio C Hamano wrote: >> Adam Borowski <kilobyte@xxxxxxxxxx> writes: >> > It looks like the periodic auto-repack backgrounds itself when it shouldn't >> > do so. This causes the command it has triggered as a part of to fail: >> >> 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. > > Just add a lock that's triggered by daemonize, and have things block on this > lock. Hmph, it defeats the whole point of running it in the background, doesn't it? How would "blocking on the lock" be different from launching "gc --auto" and waiting for it to come back? And it would also require addition of the big-repository-lock and code to take the lock sprinkled all over the place. I am not sure if we want to go there... -- 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