git@vger.kernel.org

[jc: trying to resend this message I sent late last night, because vger did not seem to have relayed it to the list for some unknown reason.]

Some people noticed that they have trouble going to remote site over ssh transport using 'next' version of git.

A brief git transport primer may be helpful to understand what is going on. When you run "git fetch" (and remember, "git pull" runs it before it runs "git merge") against a remote over ssh transport, it asks the other side to run "git-upload-pack" program. We have always used the dashed form "git-upload-pack" to make this request. Similarly, "git push" (and "git send-pack") runs "git-receive-pack" and "git archive --remote" runs "git-upload-archive" on the other end.

We have promised to move most of the git-$foobar programs out of the end users' $PATH starting from 1.6.0. After git-upload-pack moves outside $PATH, however, asking the shell invoked via ssh on the other and to run git-upload-pack won't find it, because the program is not found anywhere on $PATH. Hence, change to ask for "git upload-pack" is eventually necessary. We cannot avoid it.

Now, when the remote side runs pre-1.6.0 software, and the ssh daemon on it runs a real shell, asking for "git upload-pack" (i.e. dashless form) does not have any problem. "git" will be on your $PATH and it always knows where "git-upload-pack" is found, and it will run the program you wanted to run just fine.

However, when the remote side does not let you run a real shell, this is problematic. For example, your login shell can be set to "git-shell" (git restricted shell), which refuses to run anything but git-upload-pack, git-receive-pack, or git-upload-archive. Specifically, it does not allow you to run "git" itself with arbitrary arguments. Asking such a server to run "git upload-pack" will not work. gitosis is another example of such a server. Both git-shell and gitosis already have patches to prepare them to accept requests in either forms.

It is still possible to connect to older remote end with new clients, but you have to explicitly ask for "git-upload-pack" by using --upload-pack= option when running "git fetch", which is a bit cumbersome. Hence, we have to wait before people can update their servers, and then update the client side to start asking for "git upload-pack" and friends with dashless form.

The patch to prepare the client side for this was prepared and queued in "next" a few days ago. Consider this glitch as a part of proving the change while in next. You have a real-world opportunity to make sure that the workaround to use --upload-pack= actually works with older remote end and send in success reports ;-)

In other words, Sorry, I screwed up.

I've cut v1.5.4.6 and v1.5.5.5 releases tonight (they are tagged and pushed out already), both of which contain updates to "git-shell" so that it accepts both dashed and non-dashed forms, to make it easier for people to update their servers. At the same time, the change to the client side has been reverted from 'next' for now.

Cooking and proving the client side change in next will still be needed, but we'll postpone it for now.

Also, 1.6.0 will still install git-upload-pack and friends that are needed on the server side in $(bindir) that is on your $PATH, so that older clients will still work.

So the timeline will be:

 * Futureproofed "git-shell" and gitosis are released.  People slowly
   start deploying them.  Both old and (unreleased yet) new clients will
   be able to talk to them.

 * 1.6.0 installs git-upload-pack and friends in $(bindir) on your $PATH.
   Both old clients and 1.6.0 clients will ask for git-upload-pack and the
   real shell will still be able to find them.

 * 6 months after 1.6.0 ships, these futureproofed "git-shell" and gitosis
   will be in widespread use and nobody runs older servers anymore.  A
   major release after this happens will change the client to start asking
   for "git upload-pack" (dashless form).

   You would need --upload-pack=git-upload-pack option to talk to ancient
   servers when this happens (and past few days were preview of this).

 * 12 months after that major release ships, these new clients will be in
   widespread use and nobody runs older clients anymore.  A major release
   after this happens will stop installing git-upload-pack and friends in
   $(bindir).

   Older clients (like v1.5.0) would use --upload-pack="git upload-pack"
   to talk to new servers.

Sorry, while trying to fudge the headers and messages to avoid triggering vger's spam filter, I managed to mangle the subject of that message. It should have read:

Subject: Glitches connecting to existing remote using 'next' git

Junio C Hamano wrote:

Now that the current git won't work with older servers anyway, what about using this opportunity to add a 'version' command to the server? With such a command, such problems would seem to be quite easily avoidable in the future, since the client can discriminate based on the server's version.

I'm not sure how to implement this (the problems seem to be that (a) it needs to work with git-shell and real shells, and (b) that older clients must not be supplied with a version number in order not to break them), but perhaps this is worth pondering.

Apologies if this has been discussed before.

-- Lea

Lea Wiemann <lewiemann@gmail.com> writes:

Whoa, Wait.  Who said that?

Junio C Hamano wrote:

I meant "now that the current git won't work with *some* older servers *without adding an option*". Or did I misunderstand you?

-- Lea

Lea Wiemann, Sat, Jun 28, 2008 01:07:40 +0200:

And exactly how are the incompatibility problems avoided? By denying the service if the versions don't match?

Alex Riesen wrote:

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.)

-- Lea

Lea Wiemann <lewiemann@gmail.com> wrote:

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.