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

Jeff King [off-list ref] writes:

On Wed, Jul 18, 2018 at 11:19:01AM -0700, Junio C Hamano wrote:

quoted

quoted

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?