On Wed, Aug 26, 2015 at 12:49 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> While commit 9f673f9 (gc: config option for running --auto in >> background - 2014-02-08) helps reduce some complaints about 'gc >> --auto' hogging the terminal, it creates another set of problems. >> >> The latest in this set is, as the result of daemonizing, stderr is >> closed and all warnings are lost. This warning at the end of cmd_gc() >> is particularly important because it tells the user how to avoid "gc >> --auto" running repeatedly. Because stderr is closed, the user does >> not know, naturally they complain about 'gc --auto' wasting CPU. >> >> Daemonized gc now saves stderr to $GIT_DIR/gc.log. Following gc runs >> will not be daemonized and gc.log printed out until the user removes >> gc.log. >> >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> >> --- >> Let's try again. Compared to v2 [1], this version does not delete >> gc.log automatically any more. The user needs to take action, then >> delete gc.log to bring it background again. > > Sounds a bit more sensible, but I wonder if it is a good idea to > keep going in the first place. If the last gc run reported an > issue, would it make it likely that we would hit the same issue? > > An alternative design I have in mind is to exit "gc --auto" with > success without doing anything, after giving the new warning > message. What would be the pros-and-cons between this patch and > that alternative design? I think the alt. design is better. If anything, keep runing may produce more output and probably distract the user from the real warning. We only want to keep doing something again if it can gain us something. If we succeed at steps A and B, then fail at C. Doing A and B again next time might be worth something in general, but given the context of git-gc I don't think it is. -- 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