Inspired by a discusson on the scaling of git in the last days, I thought about starting the adventure to teach git a new transport protocol.
One of the biggest problems of a new protocol would be deployment as the users probably would not care too deeply. It should just work in the sense that the user should not even sense that the protocol changed. To do so we need to make sure the protocol is backwards compatible and works if and old client talks to a new server as well as the other way round. A later incarnation of the patch series will eventually add the possibility to add new versions of the transport protocols easily without harming the user. For now in the first revision of the series it just documents an approach of how I'd start this problem of compatibility issues. I realize this will be a bigger change to git, so I'd rather just make a small step now. The actual discussion on how to do the next protocol(s) may be started on the gitmerge conference? (bloomfilter! client speaks first!, rsyncing the refs changes!) Any thoughts on how to make it easy to teach git new protocols are very welcome. Thanks, Stefan Stefan Beller (3): Document protocol capabilities extension receive-pack: add advertisement of different protocol options receive-pack: enable protocol v2 Documentation/technical/protocol-capabilities.txt | 11 +++++++++++ builtin/receive-pack.c | 7 +++++++ 2 files changed, 18 insertions(+) -- 2.3.0.81.gc37f363 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
