Commit Briefs

Stefan Sperling

send mail


Stefan Sperling

remove unused includes


Stefan Sperling

remove unused sources



Stefan Sperling

build a list of ID/refname pairs from stdin


Stefan Sperling

read 'commit refname' pairs on stdin


Stefan Sperling

parse got-notify-email command line


Stefan Sperling

typo


Stefan Sperling

parse reply to


Stefan Sperling

switch to new email syntax


Stefan Sperling

we will probably try to use JSON for http


Stefan Sperling

tweak notify email syntax


Stefan Sperling

got-notify-email stub


Stefan Sperling

parse notification configuration


Stefan Sperling

skeleton notify process


Stefan Sperling

document gotd notification feature


Stefan Sperling

bump version number


Stefan Sperling

CHANGES for 0.97 (tags/0.97)


Stefan Sperling

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




Omar Polo

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.


Omar Polo

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@


Omar Polo

attempt to speed up the deltification for big files

The current hash table perform poorly on big files due to a small resize step that pushes the table to its limits continuously. Instead, to have both a better performing hash table and keep the memory consumption low, save the blocks in an array and use the hash table as index. Then, use a more generous resizing scheme that guarantees the good properties of the hash table. To avoid having to rebuild the table when the array is resized, save the indexes in the table, and to further reduce the memory consumption use 32 bit indices. On amd64 this means that each slot is 4 bytes instead of 8 for a pointer or 24 for a struct got_deltify_block. ok stsp@


Omar Polo

fix invalid imsg_free() in got_privsep_recv_printed_commits()

Depending on the error got_privsep_recv_imsg() may leave imsg un-initialized, so change it to always free the imsg on error if needed, so callers don't have to. got_privsep_recv_printed_commits() and got-read-patch were the only places where we could end up calling imsg_free() on uninitialized imsg, fix them. ok stsp@