Re: [PATCH 3/3] gc: do not return error for prior errors in daemonized mode

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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?