This workaround was inherited from git9, which claims that Github did not send capabilities. Protocol traces show that Github's server does in fact advertise its capabilities. Git protocol capabilities are hidden behind a NUL byte in the middle of the first refline sent by the server. This makes them easy to miss when treating a refline as a C string. I guess this is why Ori concluded that Github didn't send any capabilities. Or perhaps Github has been fixed since.

This is the beginning of support for naddy's suggestion to break this out similar to git. More code to come from stsp. ok stsp@

Also, make requirements for branch name arguments more flexible. Absolute reference names are now accepted. ok naddy@

In particular, attempt to describe the -f option better.

Previous output was: Already up-to-date New output is: Server has deleted refs/heads/branch Check this behavour in the related regression test.

Known to work against git-daemon and github Git server implementations. Tests by abieber, naddy, jrick, and myself. Man page additions reviewed by Lucas.

The tokenize_refline() function could end up reading past the end of the buffer if the refline is not terminated with whitespace or \0.

The my_capabilities pointer may remain NULL. Check for NULL before use.

Exposed by trying to run got clone -l against shithub.us over git:// found by abieber@

This will be needed for a future 'got send' command.

This will be needed by a future 'got send' command.

Rewrite got_object_commit_get_logmsg() such that only one memory allocation is made when creating a pretty version of a log message. ok naddy@