Make sure we include this header in the release tarball

These are looked for portably.

Include the logging functionality from gotd for the helpers.

Use the more predictable %F, aka %Y-%m-%d, instead of %G-%m-%d. %G follows the definition of ISO-8601 week-based year, which is weird. In particular, 2024 is one of such years with weird behaviour: $ date -jf %Y-%m-%d +"%F %G-%m-%d" 2024-12-30 2024-12-30 2025-12-30 Diff from Lucas Gabriel Vuotto (thanks!); stsp agrees

we don't need getopt.h; getopt() is in unistd.h. also sort the headers while here. ok stsp@

'got clone' already happens to support such URLs via scp-style syntax: user@127.0.0.1:~/test.git While the clone operation succeded, subsequent fetch operations would raise an error: '/~/test.git' does not appear to be a git repository Make such URLs work when they are read back from got.conf, and also on the clone command line in canonical form: ssh://user@127.0.0.1/~/test.git Not adding a test case because I don't see an easy way to add test coverage for this without spilling test data into home directories or modifying ~/.ssh/ssh_config. Problem found by Jesper Wallin.

Check what happens when patches attempt to edit or delete empty files.

if we've reached EOF without finding a match is fine if and only if the target file is empty, so add this exception. reported by naddy, ok stsp

Was suggested by Lucas some time ago. ok stsp@ with a tweak in the manual.

-R is needed on almost all other commands so this makes things consistent. Patch by Lorenz (xha)

Without this we exit the loop early and got-fetch-pack sees unexpected end-of-file on stdout trying to write its final "done\n" message. ok op@

so we can reuse it in other places like got-fetch-http later. ok op@ stsp@

tls_write() may return TLS_WANT_READ. In that case, we're stuck trying to read while we have the request still in the buffer. So, we have to retry bufio_write() regardless of the POLLIN/POLLOUT state. We'd need this only in the TLS case, but in practice it doesn't harm for the plaintext case too. In fact, we're either waiting to flush the request or we're only reading the server reply. ok stsp