{"thread":{"id":"14195","subject":"git@vger.kernel.org","startedAt":"2008-06-27T22:08:30Z","lastAt":"2008-06-29T04:08:56Z","messageCount":8,"participants":["Junio C Hamano","Lea Wiemann","Alex Riesen","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81502","messageId":"7viqvupm3l.fsf@gitster.siamese.dyndns.org","threadId":"14195","inReplyTo":null,"subject":"git@vger.kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T22:08:30Z","receivedAt":"2008-06-27T22:08:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[jc: trying to resend this message I sent late last night, because vger\ndid not seem to have relayed it to the list for some unknown reason.]\n\nSome people noticed that they have trouble going to remote site over ssh\ntransport using 'next' version of git.\n\nA brief git transport primer may be helpful to understand what is going\non. When you run \"git fetch\" (and remember, \"git pull\" runs it before it\nruns \"git merge\") against a remote over ssh transport, it asks the other\nside to run \"git-upload-pack\" program. We have always used the dashed\nform \"git-upload-pack\" to make this request. Similarly, \"git push\" (and\n\"git send-pack\") runs \"git-receive-pack\" and \"git archive --remote\" runs\n\"git-upload-archive\" on the other end.\n\nWe have promised to move most of the git-$foobar programs out of the end\nusers' $PATH starting from 1.6.0. After git-upload-pack moves outside\n$PATH, however, asking the shell invoked via ssh on the other and to run\ngit-upload-pack won't find it, because the program is not found anywhere\non $PATH. Hence, change to ask for \"git upload-pack\" is eventually\nnecessary. We cannot avoid it.\n\nNow, when the remote side runs pre-1.6.0 software, and the ssh daemon on\nit runs a real shell, asking for \"git upload-pack\" (i.e. dashless form)\ndoes not have any problem. \"git\" will be on your $PATH and it always\nknows where \"git-upload-pack\" is found, and it will run the program you\nwanted to run just fine.\n\nHowever, when the remote side does not let you run a real shell, this is\nproblematic. For example, your login shell can be set to \"git-shell\" (git\nrestricted shell), which refuses to run anything but git-upload-pack,\ngit-receive-pack, or git-upload-archive. Specifically, it does not allow\nyou to run \"git\" itself with arbitrary arguments. Asking such a server to\nrun \"git upload-pack\" will not work. gitosis is another example of such a\nserver. Both git-shell and gitosis already have patches to prepare them\nto accept requests in either forms.\n\nIt is still possible to connect to older remote end with new clients, but\nyou have to explicitly ask for \"git-upload-pack\" by using --upload-pack=\noption when running \"git fetch\", which is a bit cumbersome. Hence, we\nhave to wait before people can update their servers, and then update the\nclient side to start asking for \"git upload-pack\" and friends with\ndashless form.\n\nThe patch to prepare the client side for this was prepared and queued in\n\"next\" a few days ago. Consider this glitch as a part of proving the\nchange while in next. You have a real-world opportunity to make sure that\nthe workaround to use --upload-pack= actually works with older remote end\nand send in success reports ;-)\n\nIn other words, Sorry, I screwed up.\n\nI've cut v1.5.4.6 and v1.5.5.5 releases tonight (they are tagged and\npushed out already), both of which contain updates to \"git-shell\" so that\nit accepts both dashed and non-dashed forms, to make it easier for people\nto update their servers. At the same time, the change to the client side\nhas been reverted from 'next' for now.\n\nCooking and proving the client side change in next will still be needed,\nbut we'll postpone it for now.\n\nAlso, 1.6.0 will still install git-upload-pack and friends that are needed\non the server side in $(bindir) that is on your $PATH, so that older\nclients will still work.\n\nSo the timeline will be:\n\n * Futureproofed \"git-shell\" and gitosis are released. People slowly\n start deploying them. Both old and (unreleased yet) new clients will\n be able to talk to them.\n\n * 1.6.0 installs git-upload-pack and friends in $(bindir) on your $PATH.\n Both old clients and 1.6.0 clients will ask for git-upload-pack and the\n real shell will still be able to find them.\n\n * 6 months after 1.6.0 ships, these futureproofed \"git-shell\" and gitosis\n will be in widespread use and nobody runs older servers anymore. A\n major release after this happens will change the client to start asking\n for \"git upload-pack\" (dashless form).\n\n You would need --upload-pack=git-upload-pack option to talk to ancient\n servers when this happens (and past few days were preview of this).\n\n * 12 months after that major release ships, these new clients will be in\n widespread use and nobody runs older clients anymore. A major release\n after this happens will stop installing git-upload-pack and friends in\n $(bindir).\n\n Older clients (like v1.5.0) would use --upload-pack=\"git upload-pack\"\n to talk to new servers.\n"},{"id":"81504","messageId":"7v63rupluf.fsf@gitster.siamese.dyndns.org","threadId":"14195","inReplyTo":"7viqvupm3l.fsf@gitster.siamese.dyndns.org","subject":"Re: git@vger.kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T22:14:00Z","receivedAt":"2008-06-27T22:14:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sorry, while trying to fudge the headers and messages to avoid triggering\nvger's spam filter, I managed to mangle the subject of that message. It\nshould have read:\n\nSubject: Glitches connecting to existing remote using 'next' git\n"},{"id":"81511","messageId":"486572BC.9070201@gmail.com","threadId":"14195","inReplyTo":"7viqvupm3l.fsf@gitster.siamese.dyndns.org","subject":"Adding a 'version' command to the server (was: git@vger.kernel.org)","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-27T23:07:40Z","receivedAt":"2008-06-27T23:07:40Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> It is still possible to connect to older remote end with new clients, but\n> you have to explicitly ask for \"git-upload-pack\" by using --upload-pack=\n> option when running \"git fetch\"\n\nNow that the current git won't work with older servers anyway, what \nabout using this opportunity to add a 'version' command to the server? \nWith such a command, such problems would seem to be quite easily \navoidable in the future, since the client can discriminate based on the \nserver's version.\n\nI'm not sure how to implement this (the problems seem to be that (a) it \nneeds to work with git-shell and real shells, and (b) that older clients \nmust not be supplied with a version number in order not to break them), \nbut perhaps this is worth pondering.\n\nApologies if this has been discussed before.\n\n-- Lea\n"},{"id":"81513","messageId":"7vej6io4fy.fsf@gitster.siamese.dyndns.org","threadId":"14195","inReplyTo":"486572BC.9070201@gmail.com","subject":"Re: Adding a 'version' command to the server","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T23:15:13Z","receivedAt":"2008-06-27T23:15:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lea Wiemann writes:\n\n> Junio C Hamano wrote:\n>\n>> It is still possible to connect to older remote end with new clients, but\n>> you have to explicitly ask for \"git-upload-pack\" by using --upload-pack=\n>> option when running \"git fetch\"\n>\n> Now that the current git won't work with older servers anyway,...\n\nWhoa, Wait. Who said that?\n"},{"id":"81514","messageId":"48657591.9050805@gmail.com","threadId":"14195","inReplyTo":"7vej6io4fy.fsf@gitster.siamese.dyndns.org","subject":"Re: Adding a 'version' command to the server","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-27T23:19:45Z","receivedAt":"2008-06-27T23:19:45Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> Lea Wiemann writes:\n>> Junio C Hamano wrote:\n>>> It is still possible to connect to older remote end with new clients, but\n>>> you have to explicitly ask for \"git-upload-pack\" by using --upload-pack=\n>>> option when running \"git fetch\"\n>>\n>> Now that the current git won't work with older servers anyway,...\n> \n> Whoa, Wait. Who said that?\n\nI meant \"now that the current git won't work with *some* older servers \n*without adding an option*\". Or did I misunderstand you?\n\n-- Lea\n"},{"id":"81550","messageId":"20080628114337.GA3489@steel.home","threadId":"14195","inReplyTo":"486572BC.9070201@gmail.com","subject":"Re: Adding a 'version' command to the server (was: git@vger.kernel.org)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-06-28T11:43:37Z","receivedAt":"2008-06-28T11:43:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Lea Wiemann, Sat, Jun 28, 2008 01:07:40 +0200:\n> Junio C Hamano wrote:\n>> It is still possible to connect to older remote end with new clients, but\n>> you have to explicitly ask for \"git-upload-pack\" by using --upload-pack=\n>> option when running \"git fetch\"\n>\n> Now that the current git won't work with older servers anyway, what \n> about using this opportunity to add a 'version' command to the server? \n> With such a command, such problems would seem to be quite easily \n> avoidable in the future, since the client can discriminate based on the \n> server's version.\n\nAnd exactly how are the incompatibility problems avoided? By denying\nthe service if the versions don't match?\n"},{"id":"81552","messageId":"48662DB0.3010608@gmail.com","threadId":"14195","inReplyTo":"20080628114337.GA3489@steel.home","subject":"Re: Adding a 'version' command to the server","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-28T12:25:20Z","receivedAt":"2008-06-28T12:25:20Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Alex Riesen wrote:\n> And exactly how are the incompatibility problems avoided? By denying\n> the service if the versions don't match?\n\nNo, by talking to older servers in a way they understand it. So for \ninstance it would call \"git-upload-pack\" instead of \"git upload-pack\".\n\n(See also the SSH protocol with two versions, and I think Subversion's \nsvnserve also somehow identifies its own capabilities and/or version.)\n\n-- Lea\n"},{"id":"81597","messageId":"20080629040856.GD11793@spearce.org","threadId":"14195","inReplyTo":"48662DB0.3010608@gmail.com","subject":"Re: Adding a 'version' command to the server","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-06-29T04:08:56Z","receivedAt":"2008-06-29T04:08:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Lea Wiemann wrote:\n> Alex Riesen wrote:\n> >And exactly how are the incompatibility problems avoided? By denying\n> >the service if the versions don't match?\n> \n> No, by talking to older servers in a way they understand it. So for \n> instance it would call \"git-upload-pack\" instead of \"git upload-pack\".\n> \n> (See also the SSH protocol with two versions, and I think Subversion's \n> svnserve also somehow identifies its own capabilities and/or version.)\n\nWe already have both sides of a git native connection select\nfunctions to be used in the protocol based upon both sides having\nthe necessary capabilities. This is in heavy use today for things\nlike thin packs, sideband progress messages and remote deletion of\nbranches through git-push.\n\nSo we're doing what you suggest.\n\nThe problem we are faced with right now is when invoking Git over\nSSH we need to pass some string to the remote shell and expect\nthe remote shell to start up the program we need to talk to.\nWithout that program running there is nothing to ask the other side\nits version. :-(\n\nThis should be a one-time transition pain, as the original git\ndevelopers used git-foo-command style, but users today want just\n\"git foo-command\" style, to reduce the number of commands they\nsee with tab completion. Its the price we/they pay for making\nthat sort of change this late in the project.\n\nI'm not sure when SVN start supporting \"svn serve\" over SSH. It may\nhave been quite a while after they were already self-hosting, as\nthey started out with HTTP WebDAV as the only protocol. Thus they\nmay have already been heavily into the \"svn foo\" style of command\ninvocation and never made the \"misstep\" that Git made.\n\nOf course SVN has made _many_ other \"missteps\" that Git has done\nright since day 1. Like merge support. :-)\n\nNobody is perfect. Not even the Git developers.\n\n-- \nShawn.\n"}]}