Lea Wiemann <lewiemann@xxxxxxxxx> wrote: > Alex Riesen wrote: > >And exactly how are the incompatibility problems avoided? By denying > >the service if the versions don't match? > > No, by talking to older servers in a way they understand it. So for > instance it would call "git-upload-pack" instead of "git upload-pack". > > (See also the SSH protocol with two versions, and I think Subversion's > svnserve also somehow identifies its own capabilities and/or version.) We already have both sides of a git native connection select functions to be used in the protocol based upon both sides having the necessary capabilities. This is in heavy use today for things like thin packs, sideband progress messages and remote deletion of branches through git-push. So we're doing what you suggest. The problem we are faced with right now is when invoking Git over SSH we need to pass some string to the remote shell and expect the remote shell to start up the program we need to talk to. Without that program running there is nothing to ask the other side its version. :-( This should be a one-time transition pain, as the original git developers used git-foo-command style, but users today want just "git foo-command" style, to reduce the number of commands they see with tab completion. Its the price we/they pay for making that sort of change this late in the project. I'm not sure when SVN start supporting "svn serve" over SSH. It may have been quite a while after they were already self-hosting, as they started out with HTTP WebDAV as the only protocol. Thus they may have already been heavily into the "svn foo" style of command invocation and never made the "misstep" that Git made. Of course SVN has made _many_ other "missteps" that Git has done right since day 1. Like merge support. :-) Nobody is perfect. Not even the Git developers. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
