RFC transitioning to protocol v2
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest7 patches 23 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | pkt-line: add packet_write functionpkt-line.c pkt-line.h | +7 | 0 replies | |
| 2/7 | pkt-line: add strbuf_packet_readpkt-line.c pkt-line.h | +22 | 0 replies | |
| 3/7 | protocol: tell server that the client understands v2connect.c daemon.c | +51 | 3 replies | |
| 4/7 | t: fix ssh tests to cope with using '-o SendEnv=GIT_PROTOCOL't/ t/ t/ | +8 | 0 replies | |
| 5/7 | http: send Git-Protocol-Version headerhttp.c t/ | +9 | 1 reply | |
| 6/7 | transport: teach client to recognize v2 server responsebuiltin/ builtin/ connect.c +3 more | +178 | 0 replies | |
| 7/7 | upload-pack: ack version 2upload-pack.c | +11 | 2 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 0/7] transitioning to protocol v2
Another version of Git's wire protocol is a topic that has been discussed and attempted by many in the community over the years. The biggest challenge, as far as I understand, has been coming up with a transition plan to using the new server without breaking existing clients and servers. As such this RFC is really only concerned with solidifying a transition plan. Once it has been decided how we can transition to a new protocol we can get into decided what this new protocol would look like (though it would obviously eliminate the ref advertisement ;).
The best way to preserve functionality with old servers and clients would be to communicate using the same end point but have the client send a bit of extra information with its initial request. This extra information would need to be sent in such a way that old servers ignore it and operate normally (using protocol v1). The client would then need to be able to look at a server's response to determine whether the server understands and is speaking v2 or has ignored the clients request to use a newer protocol and is speaking v1.
Patches 1-5 enable a client to unconditionally send this back-channel information to a server. This is done by sending a version number after a second NUL byte in git://, in the envvar GIT_PROTOCOL in file:// and ssh://, and in an http header in http://, https://. Patches 6-7 teach a client and upload-pack to send and recognize a request to use protocol v2.
The biggest question I'm trying to answer is if these are reasonable ways with which to communicate a request to a server to use a newer protocol, without breaking current servers/clients. As far as I've tested, with patches 1-5 applied I can still communicate with current servers without causing any problems.
Any comments/discussion is welcome!
Brandon Williams (7):
pkt-line: add packet_write function
pkt-line: add strbuf_packet_read
protocol: tell server that the client understands v2
t: fix ssh tests to cope with using '-o SendEnv=GIT_PROTOCOL'
http: send Git-Protocol-Version header
transport: teach client to recognize v2 server response
upload-pack: ack version 2
builtin/fetch-pack.c | 4 +- builtin/send-pack.c | 5 +- connect.c | 196 +++++++++++++++++++++++++++---------------- daemon.c | 28 ++++++- http.c | 7 ++ pkt-line.c | 27 ++++++ pkt-line.h | 2 + remote-curl.c | 7 +- remote.h | 22 ++++- t/lib-proto-disable.sh | 1 + t/t5551-http-fetch-smart.sh | 2 + t/t5601-clone.sh | 10 +-- t/t5602-clone-remote-exec.sh | 4 +- transport.c | 60 +++++++++++-- upload-pack.c | 11 +++ 15 files changed, 286 insertions(+), 100 deletions(-)
Signature · 1 line
2.14.1.342.g6490525c54-goog