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.

When an operation is interrupted add a trailing message to status output which displays the operation and branches involved. This information will be useful when diagnosing problem reports and it helps new users with contextualizing multi-operation work tree state. ok op@

found by op's regress builder

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@

We now know that unveil(2) will never traverse exec. No need to wait with unveil until the editor has been run. ok op@

We now know that unveil(2) will never traverse exec. No need to wait with unveil until the editor has been run. ok op@

We now know that unveil(2) will never traverse exec. No need to wait with unveil until the editor has been run. ok op@

We now know that unveil(2) will never traverse exec. No need to wait with unveil until the editor has been run. ok op@

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.

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