Commits


add some helper functions to compute hashes This adds a set of functions to abstract over SHA1Init, SHA1Update, SHA1Final, their respective SHA256 variants and how to compare digests. Replace all the SHA1*() usage with the new APIs. It's a preparatory step for sha256 handling. ok stsp@


provide functions to parse/serialize different hashes it abstracts over the hash type and ensures that object ids are zero'ed before their sha1 digest is written. Needed by the incoming sha256 support. ok stsp@


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>


fix "got fetch" hang against out-of-date remote repositories Do not assume that remote repositories will always have our objects. In Git protocol terms: Do not wait for an ACK from the server before sending the final "done" message. Otherwise servers might be waiting for more have-lines from us in order to find a common ancestor, which will never be sent by us. Problem reported by James Cook who also provided an initial test case ok op@


got: further fetch tweaks to prevent unintended fetches Implement stsp's suggestion to only fetch remote's HEAD if the symref refs/remote/*/HEAD exists, and its target no longer matches the remote HEAD. This ensures users tracking a project won't miss a change in HEAD, while also fixing the issue reported by naddy where HEAD was fetched by default even though a specific, potentially less active, branch is cloned, resulting in a repository with more commits than necessary. In addition, unless 'got fetch -b <branch>' is used, the remote HEAD branch will be fetched if branches are not set in got.conf and there is no work tree to ascertain a branch, or said branches are not found on the server. ok stsp@


backout got: always fetch remote HEAD except when -b is used As pointed out by naddy, this behaviour is not ideal when users want to limit their repository to a particular branch which will diverge from HEAD over time, such as -stable branches. See https://marc.gameoftrees.org/mail/1676388048.8632_0.html


got: always fetch remote HEAD except when -b is used Rather than only fetch HEAD when there are no branches set in got.conf and there is no branch to be inferred from a work tree, or said branches don't exist on the server, always fetch HEAD unless 'got fetch -b branch' is used. ok stsp@


make 'got fetch -b branch' error reporting more helpful The patch to got-fetch-pack.c was written by stsp with only minor tweaks by me. Regress updated to account for the change in reporting. stsp's original got-fetch-pack.c diff ok op jamsek ok stsp@


special case 'got fetch -b <branch>' to only fetch <branch> As discussed on irc, this drops the implicit remote HEAD fetch when -b is used. got.1 has been updated to make the new fetch behaviour clear. ok stsp@


got: use intermediate pointers to plug leak on realloc And save worktree_branch_len for reuse. ok stsp@ and op@


fix interaction of 'got fetch -b', got.conf, and work tree Without branches in got.conf for a remote, and without -b/-R options, the fallback to HEAD would only work when not invoked in a work tree. With this fix 'got fetch' should behave as described in the man page. The -b option now overrides both got.conf and the fallback to the work tree's branch. And fallback to HEAD works as expected when invoked in a repository. Also, do not strictly require remote repositories to provide a branch from the refs/heads/ namespace. In such cases users should be able to use -R to select something to fetch. ok jamsek


got_imsg_fetch_ref: use struct instead of buffer for id ok stsp@


got_imsg_fetch_have_ref: use struct instead of buffer for id ok stsp@


replace malloc+memcpy with strndup. no functional change intended ok stsp@