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).
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.
I could not find a 'maintenance.quiet' option (or similar) in the
config. Is there a way to do this currently?
Thanks,
Clément
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.
Thanks,
-Stolee
On Mon, Mar 29 2021, Derrick Stolee wrote:
On 3/29/2021 12:45 PM, Clement Moyroud wrote:
quoted
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.
quoted
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.
quoted
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:
https://habilis.net/cronic/
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.