Jeff King <peff@xxxxxxxx> writes: > On Wed, Jul 18, 2018 at 11:19:01AM -0700, Junio C Hamano wrote: > >> > It's also still inconsistent in the daemonize case. The run that yields >> > the error won't return a non-zero exit. But the next run will exit with >> > "2". >> >> I do not see this particular "inconsistency" a problem. The run >> that first discovers the problem by definition cannot return with >> non-zero; not waiting until finding out the outcome is the whole >> point of running in the background and giving control back early. > > I guess I just see it as encouraging a non-robust flow. I can see > somebody thinking they should care about "gc --auto" errors, because > they can turn up latent repository corruption (because most operations > try to only look at the objects they need to, and gc inherently > considers every object). But doing so would give a very delayed > notification for a repository that is handled infrequently. So finding > out about a corruption that we detected might takes weeks or months. > > I dunno. If your primary motivation is not finding latent problems, but > loudly complaining when gc does not make forward progress, I suppose it > makes more sense. I am not sure either. If your primary motivation is to protect yourself from ignoring gc failures that could be an indication of possible repository corruption, you wouldn't be running it backgrounded in the first place, I woudl guess. And if you are backgrounding, with "exit with 2, not hide it with 0" approach, you would have a better chance to notice, no?
