regress: make server tests more robust against race hazard Add a delay after starting the server background process to keep server and client from racing against each other, which would lead to failures when the client ran before the server. ok op

display abbreviated commit/tag IDs in email notification subject lines This should make it somewhat easier to keep track of discussion threads when someone replies to a commit notification to discuss the changes.

replace date, strftime %G-%m-%d with %F Use the more predictable %F, aka %Y-%m-%d, instead of %G-%m-%d. %G follows the definition of ISO-8601 week-based year, which is weird. In particular, 2024 is one of such years with weird behaviour: $ date -jf %Y-%m-%d +"%F %G-%m-%d" 2024-12-30 2024-12-30 2025-12-30 Diff from Lucas Gabriel Vuotto (thanks!); stsp agrees

fix gotd notification test failures due to missing shell quoting The expected output generated by test scripts was wrong on days with a single-digit date. Found by Omar's regress builder. ok op@

adjust expected output in the regress

add a messagelen field in the notifications Similar to the `got cat' output; it's needed to un-ambiguosly parse the content of the notification, which is already useful to parse the email content and invaluable for the upcoming got-notify-http. ok stsp@

add initial support for commit notifications to gotd(8) At present only email notifications are implemented. Code for HTTP notifications is not yet finished, hence HTTP-related documentation remains hidden for now. This adds a new 'notify' process which has an "exec" pledge. It runs helper programs which implement the notification transport layer, such as got-notify-email which speaks SMTP. This design avoids having to link all of gotd with network libraries and related crypto libraries. Notification content is generated by the 'repo_write' process. Commit log messages and diffstats are written to a file which the 'notify' process will pass on to its helpers on stdin. The default output looks similar to 'got log -d'. If too many new commits are present the output looks similar to 'got log -s' instead. Tags always look like 'got tag -l'. The session process coordinates generation of notifications. It maintains a notification queue which holds one notification per updated reference, and passes notification requests from this queue to the 'repo_write' process for notification content creation and then to the 'notify' process for notification delivery. Only one notification can be in flight at a time to avoid file descriptor starvation if many references get updated in a single client session. ok op@