ok stsp

ok stsp

The expected output generated by test scripts was wrong on days with a single-digit date. Found by Omar's regress builder. ok op@

at the moment it is indistinguishable from the created tag.

add test_branch_created(). at the moment this is not different from a "normal" commit notification but it'll change in the future and it's handy to have it for an upcoming branch removed notification.

will help to differentiate these notification objects from the others.

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@

long lines are not manegeable. split the json over multiple lines, then use ed to join everything back in a single one.

The http-server script is already validating the headers, doing so in the regress too is not helpful.

ok stsp@