Re: Adding a 'version' command to the server

["Shawn O. Pearce" <spearce@spearce.org>]

Lea Wiemann <lewiemann@gmail.com> 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.