fmt

plug memleak in parsing the notify options The strings need to be released regardless of the process parsing the file.

portable: enable got-notify-email Now that gotd has the start of helpers, got-notify-email is the first. This is still behind the --enable-gotd flag.

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@

make output of 'got ref -l' more consistent Ensure that got ref -l provides consistent output regardless of whether references are packed or not. Problem reported by naddy@ Also make 'got ref -l name' work consistently when the provided argument is the name of a reference, rather than a ref-prefix. ok naddy

introduce got_poll_read_full_timeout() Upcoming gotd code needs to avoid infinite network socket read timeouts.

add support for reading blobs to object_open_io.c

introduce got_opentemp_truncatefd()

simplify SUBDIR+=cvg handling; ok stsp jamsek

CHANGES for 0.91

visit the cvg/ subdir during 'make clean' and 'make obj'

Exclude cvg from release builds

gotwebd: drop a few unneeded SRCS fileindex.c, worktree.c, worktree_open.c and patch.c are not used in gotwebd. ok stsp

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.

use a define for vi(1) path This is intended to aid -portable, since other systems may have vi installed in a different place, or maybe prefer to ship with a different default editor. ok stsp@

speed up got tag -l by caching timestamps in got_ref_cmp_tags() performance problem reported by naddy@

portable: release 0.97

bump version number

CHANGES for 0.97

add an xfail test for a case where rebase fails to forward a branch Because 'got rebase' only does a first-parent traversal it will try to rebase commits which appear in the history of a branch, even when the branch to be rebased is already based on that history. This results in spurious merge conflicts as existing changes get re-applied. The desired behaviour would be that 'got rebase' forwards the branch, as it does when the 'got merge -M' command used by this test case is replaced by a simple 'got merge' which avoids creating a merge commit. Problem reported by naddy in the "Landry's firefox repository" thread: https://marc.gameoftrees.org/mail/1706721001.20565_0.html

add a test which checks what happens when rebasing onto a merge commit

add a test which checks what happens when a merge commit is rebased

adjust min_datalen in a few places Fix the computation of min_datalen that was forgotten in 8f137979fc5e284a136cf8950e8b3895d7ea208b. got_privsep_recv_imsg() already takes care of converting GOT_IMSG_ERROR to errors, so just how we didn't need to call recv_imsg_error() at all, we don't need to include it in the requested min_datalen.

swap the order of the checks to not hide an error If a libexec process returns an GOT_IMSG_ERROR that happens to be smaller than the requested min_datalen, got_privsep_recv_imsg() returns GOT_IMSG_PRIVSEP_LEN hiding the original error. ok stsp@