Commits


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.


store repo_child_iev in gotd_session rather than gotd_session_client


track session state in struct gotd_session instead of got_session_client Eventually, I would like to disconnect clients before notifications are generated. This change helps pave the way towards this goal.


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.


reuse existing repository struct in gotd session update_ref() Avoids pointlessly opening and closing a separate repository instance.


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@


avoid opening objects in the gotd session process for no reason The session process opened an object as part of a sanity check and simply closed it again. Opening an object involves decompression and combination of deltas. Add a new interface which checks whether an object ID exists without such overhead and call it from gotd.


make gotd flush pending messages before disconnecting the client upon success This prevents gotd from closing the client connection before ref-update status reports have been sent. Seen while testing gotd on Linux, though I see no obvious reason why this race would not trigger on OpenBSD.


gotd: stop logging "unexpected end of file" when a client decides to disconnect


unveil repositories read-only in gotd session process while serving fetches ok op@


make gotd show relevant commit hashes in error message if ref-updates collide


make gotd avoid re-writing existing ref files when a ref-update is a no-op


make gotd avoid a "failed to push some refs" error from no-op 'git push' gotsh was sending errors such as "unexpected end of file" and "unexpected flush-pkt" to the client when the client disconnected immediately after receiving reference announcements from the server. As a result, 'git push' with both sides up-to-date would show an obscure error message: = [up to date] main -> main error: failed to push some refs to 'ssh://example.com/git/repo.git Now we see: = [up to date] main -> main Everything up-to-date ok jamsek


rename lib/sha1.c to lib/hash.c It will soon grow functions to deal with sha256 too. stsp@ agrees.


include sha2.h too where sha1.h is included In preparation for wide sha256 support; stsp@ agrees. Change done mechanically with find . -iname \*.[cy] -exec sam {} + X ,x/<sha1\.h>/i/\n#include <sha2.h>


drop double process name from some gotd logs i.e. "listen: listen: shutting down" -> "listen: shutting down" the procname is already prepended by vlog() ok jamsek


rename a function for clarity


zap trailing whitespace


gotd, gotadmin: install packfiles and index files as 0444 gotd used 0600 (due to mkstemps(3)), gotadmin 0644; change it to 0444 since packfiles shouldn't change once created. Mirrors what git does. ok stsp@


gotd: implement the delete-refs capability Allow clients to run "got send -d" against gotd. Clients will send a zero-id as new id for a reference and, in the special but more common case of just deleting and not updating, no pack file will be sent. ok and tweaks by stsp@


make gotd session process accept just one flush packet at a time ok jamsek


gotd: fix "bad packfile with zero objects" error while creating branches Clients will send an empty pack file if they are only creating new references and have no objects to upload. Make gotd handle this and add a regression test which triggers the bug. Problem found by op@. The new regression test caught an unrelated issue where the client connection was left lingering after references had been updated, which made 'got send' followed by 'got clone -l' fail with the connection limit configured for the test suite (just one connection is allowed at a time). Fix this as well. ok op@


fix an issue where gotd fails to accept multiple have-lines from clients ok op, jamsek