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. This handles all cases: * --auto in the middle of a command: the block will kick in immediately, effectively reverting to non-daemonized version * --auto at the end, the user does nothing: gc will finish its work in the background, just as you wanted * --auto at the end, the user starts a new write two seconds later: gc works in the foreground with those 2 seconds headstart The only loss is the lack of a progress indicator, and even that can be done. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- 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