Hi Frank, > - just send the emails immediately, without the daemon stuff; if the > delays are there to try to sequentialize them, consider instead > getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to > let MUA's sort properly at reception
We can certainly add a non-daemon mode to the hooks. I don't know when I'd have time to work on this enhancement, unfortunately. > - invoke the email sending wrapped in a "systemd-run --user" > deferred execution gadget, including a "sleep XXX" if you must > keep time-hope-based sequencing > > - move email stuff entirely out of the hooks; these repos are "public > property" anyhow, and we can put cron jobs in place elsewhere to > trigger email notifications about commits; heck, they could run the > hook code itself later, just feed it retrospective git-hook lines You can configure the hooks to turn emailing off completely. From memory, this triggers a warning message on the user end when they do the push, just to let them know to not expect emails. The downside of going this way, other than the minor annoyance above, is that you lose track of who did the push. Right now, the emails allows you to derive the information from the emails' from field. Thinking more long term, I think there are talks about using a more comprehensive system for source and contribution management, similar to products such as GitLab or GitHub. Those will likely come with they own set of tooling for things such as alerting, pre-commit checks, keeping track of who submitted, who reviewed and approved, and who pushed. That's why I tend to think that, for the moment, I'd go the simplest route overall: In this case, I think the simplest is to just have a way to disable the daemon mode, and just have the users wait. In the vast majority of cases, the wait will be a few seconds. Even with a patch-series of a 100 patches, it would mean a 1min40s wait. Very bearable. If you agree, we can create an issue for it on the git-hooks repoisitory on GitHub. -- Joel
