archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Derrick Stolee <>
Cc: Clement Moyroud <>,
	Git List <>
Subject: Re: Running scheduled maintenance in quiet mode
Date: Tue, 30 Mar 2021 11:16:45 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Mar 29 2021, Derrick Stolee wrote:

> On 3/29/2021 12:45 PM, Clement Moyroud wrote:
>> Hello,
>> Now that Git v2.31.0 has the fix for 'git maintenance register' on
>> bare repositories, I've enabled it. I'm now getting a fairly useless
>> daily e-mail with a couple of hashes listed (no other info).
> Thanks for your interest in the feature! Sorry this is a
> frustrating experience.
>> I'd like to disable this e-mail and get the configuration to stick -
>> changing my Crontab with either --quiet or a /dev/null redirect works,
>> but the next time 'git maintenance start' is called, this will be
>> rewritten.
> You are right about that. We could alter the implementation of
> 'start', and the only downside is that you would need to rerun
> the command to avoid those problems.
> For now, you can stick to 'git maintenance register' instead of
> 'start' so the crontab schedule is not overwritten.
>> I could not find a 'maintenance.quiet' option (or similar) in the
>> config. Is there a way to do this currently?
> This could also be an interesting workaround. To be distinct from
> the crontab approach, it would probably be necessary to also make
> the `git maintenance run --auto` output quiet by default, too.
> I'm on the side of modifying the crontab schedule. I'd like to
> hear other opinions before starting the work, though.

The behavior of crond on *nix systems of e-mailing on output and
ignoring exit codes is probably one of the worst design choices of that
family of systems.

I think the only sane way to deal with that is to run the relevant
program through something like chronic or any of the numerous other
"buffer up cmd output and check exit code, spew if non-zero" wrappers:

We could even ship such a wrapper ourselves, or ship chronic itself
(it's like ~20 lines of Perl).

Down the road of catering to cron's behavior in individual programs lies
madness. Instead being able to run your program, emit diagnostics output
and decide on the exit code at the end you end up having to decide at
any given leaf node in your program whether what you have there is
important enough to impact the eventual exit code, because otherwise you
should be quiet least cron sends an E-Mail.

You essentially end up re-implementing something like chronic in your
program. I've seen *way* too many such hacks of buffering output until
the end that could have trivially been implemented via chronic.

      reply	other threads:[~2021-03-30  9:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 16:45 Running scheduled maintenance in quiet mode Clement Moyroud
2021-03-29 19:14 ` Derrick Stolee
2021-03-30  9:16   ` Ævar Arnfjörð Bjarmason [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).