Commits


remove trailing whitespaces


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@


rename got_commit_graph_iter_start() to got_commit_graph_bfsort() This function begins a breadth-first traversal. The new name makes it easier to distinguish from got_commit_graph_toposort().


render_notification: don't leak fd on error


don't ignore err while preparing notifications contents


display process title in syslog when a gotd child process exits


get rid of gotd client_id field where it is not needed This ID was necessary back when session and repo processes supported connections from multiple clients. Nowadays, these processes run per connection and exit once a single client session has been served. The other processes already identify the client via the session/repo file descriptor which has sent an imsg.


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@


avoid a rename/stat race when gotd installs a new pack and then uses it Reset the cached repository's pack directory mtime after installing a new pack and pack index file. I have observed the mtime of the pack directory as reported by stat(2) remaining unchanged, until some time has passed beyond the rename(2) calls used to install the pack file and its index. If gotd immediately tries to read objects installed in a new pack file then the mtime reported by stat(2) might appear as unchanged. gotd will then fail to update its cached list of pack index files and not find the newly installed objects. Clearing the cached timestamp forces a readdir(3) call which does expose the newly installed pack index file as expected. Not sure whether stat(2) is supposed to immediately expose mtime changes after a rename(2). If so then this might warrant digging into the kernel. Seen while running regression tests for upcoming gotd notification support.


remove unneded wbuf->fd = -1 There's no need to set the fd to -1 on ibufs created with imsg_create(3), and it was probably never needed.


convert to use imsg_get_fd() While here also fix a fd leak in got-read-pack. We were dup'ing imsg.fd without closing imsg.fd later; instead just use imsg_get_fd() to extract the file descriptor. Tested by falsifian and Kyle Ackerman, thanks! 'go ahead' stsp@


fix typo in gotd debug messages: receving -> receiving


fix spurious empty packfile error from gotd when rewinding a branch ok op@


add support for protecting references against 'got send -f' to gotd ok op@


gotd: remove more (all?) double process names in log