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

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

ok op@

ok stsp

ok stsp

will help to differentiate these notification objects from the others.

To support the other types of notifications, we can't just peek at the first byte and decide wether it's a short or long format. Refactor the parsing so that there's one main entrypoint, jsonify(), that calls jsonify_comment() or jsonify_comment_short() depending on the format of the line. Other "line types" will be added as a follow-up to support the other notification types.

Split the author/committer in sub-fields, rename author -> committer in the short format parser and cache the author for the long format in case it's the same user as the committer. Put a copy of the first line of the commit message in the "short_message" field. There's some redundancy now, but it's to make consuming easier. ok stsp@

JSON strings are made of UNICODE codepoints, of which only \, " and control characters have to be escaped, and the whole document MUST be encoded in UTF-8. The current code generates invalid strings for non-ASCII characters, so it has to be made UTF-8 aware. tedu' isu8cont() can't be used since it allows surrogate pairs and overlong sequences which will cause decoding errors on the receiving side. Similarly, mbtowc() depends on the current locale and could cause issues in -portable. Instead, bundle Björn Höhrmann's "Flexible and Economical UTF-8 Decoder" and use it to parse the text. Decoding errors results in the replacement character U+FFFD being emitted and the bytes considered so far to be discarded; the decoder is then restarted with the next byte. Git commit messages don't carry the notion of the encoding, but it's reasonable to expect UTF-8 (which is a superset of ASCII). For other more esotic encodings, the commit id can be used to manually extract the data. ok stsp@

At least for now, we don't support following redirects nor retrying the post, so consider a 3XX status a failure too.

ok stsp@