{"thread":{"id":"39083","subject":"support git+mosh for unreliable connections","startedAt":"2015-04-15T13:07:24Z","lastAt":"2015-04-22T06:54:05Z","messageCount":15,"participants":["Pirate Praveen","Dennis Kaarsemaker","Michael J Gruber","Johannes Schindelin","Trevor Saunders","Ilari Liusvaara","Andreas Krey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259404","messageId":"552E628C.7040809@debian.org","threadId":"39083","inReplyTo":null,"subject":"support git+mosh for unreliable connections","fromName":"Pirate Praveen","fromEmail":"praveen@debian.org","sentAt":"2015-04-15T13:07:24Z","receivedAt":"2015-04-15T13:07:24Z","isPatch":false,"sender":{"key":"praveen@debian.org","avatar":null},"body":"Hi,\n\n When working with big projects over a slow, unreliable connection,\ncurrently there is no way to resume a clone or pull when the connection\nbreaks. mosh is a better replacement for ssh over unreliable\nconnections. supporting git+mosh protocol will go a long way in\nsupporting people who work with unreliable, mobile networks, especially\nin developed countries (I personally have to try many times when working\nwith large projects as my 3g mobile connection keeps dropping. I\nrecently discovered mosh and it works like a charm. More about mosh\nhttps://mosh.mit.edu/\n\nThanks\nPraveen\n\n"},{"id":"259405","messageId":"1429105521.14175.0.camel@kaarsemaker.net","threadId":"39083","inReplyTo":"552E628C.7040809@debian.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-04-15T13:45:21Z","receivedAt":"2015-04-15T13:45:21Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On wo, 2015-04-15 at 18:37 +0530, Pirate Praveen wrote:\n> Hi,\n> \n> When working with big projects over a slow, unreliable connection,\n> currently there is no way to resume a clone or pull when the connection\n> breaks. mosh is a better replacement for ssh over unreliable\n> connections. supporting git+mosh protocol will go a long way in\n> supporting people who work with unreliable, mobile networks, especially\n> in developed countries (I personally have to try many times when working\n> with large projects as my 3g mobile connection keeps dropping. I\n> recently discovered mosh and it works like a charm. More about mosh\n> https://mosh.mit.edu/\n\nmosh isn't a generic transport though, it's a udp-based session state\nsynchronization protocol. I don't think it can be used as a git\ntransport.\n\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"259406","messageId":"552E6D07.5030903@drmicha.warpmail.net","threadId":"39083","inReplyTo":"552E628C.7040809@debian.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-15T13:52:07Z","receivedAt":"2015-04-15T13:52:07Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Pirate Praveen venit, vidit, dixit 15.04.2015 15:07:\n> Hi,\n> \n> When working with big projects over a slow, unreliable connection,\n> currently there is no way to resume a clone or pull when the connection\n> breaks. mosh is a better replacement for ssh over unreliable\n> connections. supporting git+mosh protocol will go a long way in\n> supporting people who work with unreliable, mobile networks, especially\n> in developed countries (I personally have to try many times when working\n> with large projects as my 3g mobile connection keeps dropping. I\n> recently discovered mosh and it works like a charm. More about mosh\n> https://mosh.mit.edu/\n\nWhat would that require git to do, beyond taking whatever you tell it\n(using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n\nMichael\n"},{"id":"259407","messageId":"552E732E.20107@debian.org","threadId":"39083","inReplyTo":"552E6D07.5030903@drmicha.warpmail.net","subject":"Re: support git+mosh for unreliable connections","fromName":"Pirate Praveen","fromEmail":"praveen@debian.org","sentAt":"2015-04-15T14:18:22Z","receivedAt":"2015-04-15T14:18:22Z","isPatch":false,"sender":{"key":"praveen@debian.org","avatar":null},"body":"On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n> What would that require git to do, beyond taking whatever you tell it\n> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n> \n> Michael\n> \n\nMay be support git+mosh as a protocol, since it is not a drop in\nreplacement. It is redesigned remote shell. The ideas it uses for\nsession resumption needs to be reimplemented. This will need support\nfrom git, because it needs server side to be modified. Use SSP to return\nthe the current progress for a particular session (it uses AES session ids).\n\nSo when a client connect with a session id, git server side can respond\nwith the current state, how many objects received in that session, and\nclient can continue from where it stopped. Client also will need to\nstore session information.\n\n\n\n"},{"id":"259408","messageId":"20bd52de595018f49eeeea64128e3a77@www.dscho.org","threadId":"39083","inReplyTo":"552E628C.7040809@debian.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-04-15T14:22:40Z","receivedAt":"2015-04-15T14:22:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Praveen \"Arrrr\",\n\nOn 2015-04-15 15:07, Pirate Praveen wrote:\n\n> When working with big projects over a slow, unreliable connection,\n> currently there is no way to resume a clone or pull when the connection\n> breaks. mosh is a better replacement for ssh over unreliable\n> connections. supporting git+mosh protocol will go a long way in\n> supporting people who work with unreliable, mobile networks, especially\n> in developed countries (I personally have to try many times when working\n> with large projects as my 3g mobile connection keeps dropping. I\n> recently discovered mosh and it works like a charm. More about mosh\n> https://mosh.mit.edu/\n\n>From https://github.com/keithw/mosh:\n\n> Mosh does not support X forwarding or the non-interactive uses of SSH, including port forwarding.\n\nIn particular it \"does not support [...] the non-interactive uses of SSH\", which the git+mosh transport would require, though.\n\nThat means that you would have to invest quite a bit of effort into enhancing mosh to *support* the non-interactive uses of SSH before you could start implementing `git-remote-mosh`...\n\nCiao,\nJohannes\n"},{"id":"259409","messageId":"0cf0485caae569a71a8bd1aa8d1033cb@www.dscho.org","threadId":"39083","inReplyTo":"552E732E.20107@debian.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-04-15T14:41:42Z","receivedAt":"2015-04-15T14:41:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Praveen,\n\nOn 2015-04-15 16:18, Pirate Praveen wrote:\n> On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n>> What would that require git to do, beyond taking whatever you tell it\n>> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n> \n> May be support git+mosh as a protocol, since it is not a drop in\n> replacement. It is redesigned remote shell. The ideas it uses for\n> session resumption needs to be reimplemented. This will need support\n> from git, because it needs server side to be modified. Use SSP to return\n> the the current progress for a particular session (it uses AES session ids).\n\nIt will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further.\n\n> So when a client connect with a session id, git server side can respond\n> with the current state, how many objects received in that session, and\n> client can continue from where it stopped. Client also will need to\n> store session information.\n\nNo, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh.\n\nCiao,\nJohannes\n"},{"id":"259412","messageId":"552E7927.5030803@debian.org","threadId":"39083","inReplyTo":"20bd52de595018f49eeeea64128e3a77@www.dscho.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Pirate Praveen","fromEmail":"praveen@debian.org","sentAt":"2015-04-15T14:43:51Z","receivedAt":"2015-04-15T14:43:51Z","isPatch":false,"sender":{"key":"praveen@debian.org","avatar":null},"body":"On Wednesday 15 April 2015 07:52 PM, Johannes Schindelin wrote:\n> From https://github.com/keithw/mosh:\n> \n>> Mosh does not support X forwarding or the non-interactive uses of SSH, including port forwarding.\n> \n> In particular it \"does not support [...] the non-interactive uses of SSH\", which the git+mosh transport would require, though.\n> \n> That means that you would have to invest quite a bit of effort into enhancing mosh to *support* the non-interactive uses of SSH before you could start implementing `git-remote-mosh`...\n> \n> Ciao,\n> Johannes\n> \n\nQ: Are the mosh principles relevant to other network applications?\n\n We think so. The design principles that Mosh stands for are\nconservative: warning the user if the state being displayed is out of\ndate, serializing and checkpointing all transactions so that if there\nare no warnings, the user knows every prior transaction has succeeded,\nand handling expected events (like roaming from one WiFi network to\nanother) gracefully.\n\nCan the ideas be used to resume a pull, push or clone operation?\nEspecially serializing and checkpointing.\n\n"},{"id":"259413","messageId":"20150415153317.GA21768@tsaunders-iceball.corp.tor1.mozilla.com","threadId":"39083","inReplyTo":"0cf0485caae569a71a8bd1aa8d1033cb@www.dscho.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Trevor Saunders","fromEmail":"tbsaunde@tbsaunde.org","sentAt":"2015-04-15T15:33:17Z","receivedAt":"2015-04-15T15:33:17Z","isPatch":false,"sender":{"key":"tbsaunde@tbsaunde.org","avatar":null},"body":"On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:\n> Hi Praveen,\n> \n> On 2015-04-15 16:18, Pirate Praveen wrote:\n> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n> >> What would that require git to do, beyond taking whatever you tell it\n> >> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n> > \n> > May be support git+mosh as a protocol, since it is not a drop in\n> > replacement. It is redesigned remote shell. The ideas it uses for\n> > session resumption needs to be reimplemented. This will need support\n> > from git, because it needs server side to be modified. Use SSP to return\n> > the the current progress for a particular session (it uses AES session ids).\n> \n> It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further.\n\nis that really relevent? mosh doesn't support things like X forwarding\nor port forwarding, but it certainly does support ssh \nand then doing IO. It might not support not doing terminal emulation\nstuff, but that seems like a simple thing to change in principal at which\npoint I think it would support enough of ssh's functionality its a drop\nin replacement as far as git is concerned. Seems to me mosh is close\nenough on its own its worth experimentation by someone who cares.\n\nTrev\n\n> > So when a client connect with a session id, git server side can respond\n> > with the current state, how many objects received in that session, and\n> > client can continue from where it stopped. Client also will need to\n> > store session information.\n> \n> No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh.\n> \n> Ciao,\n> Johannes\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"259431","messageId":"31749ad9ba57ada7f9c553191ffaddb3@www.dscho.org","threadId":"39083","inReplyTo":"20150415153317.GA21768@tsaunders-iceball.corp.tor1.mozilla.com","subject":"Re: support git+mosh for unreliable connections","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-04-15T17:46:15Z","receivedAt":"2015-04-15T17:46:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Trevor,\n\nOn 2015-04-15 17:33, Trevor Saunders wrote:\n> On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:\n>>\n>> On 2015-04-15 16:18, Pirate Praveen wrote:\n>> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n>> >> What would that require git to do, beyond taking whatever you tell it\n>> >> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n>> >\n>> > May be support git+mosh as a protocol, since it is not a drop in\n>> > replacement. It is redesigned remote shell. The ideas it uses for\n>> > session resumption needs to be reimplemented. This will need support\n>> > from git, because it needs server side to be modified. Use SSP to return\n>> > the the current progress for a particular session (it uses AES session ids).\n>>\n>> It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further.\n> \n> is that really relevent? mosh doesn't support things like X forwarding\n> or port forwarding, but it certainly does support ssh \n> and then doing IO.\n\nAh, so mosh's README lied to me!\n\nIf `mosh @ ` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it?\n\nCiao,\nJohannes\n It might not support not doing terminal emulation\n> stuff, but that seems like a simple thing to change in principal at which\n> point I think it would support enough of ssh's functionality its a drop\n> in replacement as far as git is concerned. Seems to me mosh is close\n> enough on its own its worth experimentation by someone who cares.\n> \n> Trev\n> \n>> > So when a client connect with a session id, git server side can respond\n>> > with the current state, how many objects received in that session, and\n>> > client can continue from where it stopped. Client also will need to\n>> > store session information.\n>>\n>> No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh.\n>>\n>> Ciao,\n>> Johannes\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"259438","messageId":"20150415185907.GC21768@tsaunders-iceball.corp.tor1.mozilla.com","threadId":"39083","inReplyTo":"31749ad9ba57ada7f9c553191ffaddb3@www.dscho.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Trevor Saunders","fromEmail":"tbsaunde+mozilla@tbsaunde.org","sentAt":"2015-04-15T18:59:07Z","receivedAt":"2015-04-15T18:59:07Z","isPatch":false,"sender":{"key":"tbsaunde+mozilla@tbsaunde.org","avatar":null},"body":"On Wed, Apr 15, 2015 at 07:46:15PM +0200, Johannes Schindelin wrote:\n> Hi Trevor,\n> \n> On 2015-04-15 17:33, Trevor Saunders wrote:\n> > On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:\n> >>\n> >> On 2015-04-15 16:18, Pirate Praveen wrote:\n> >> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n> >> >> What would that require git to do, beyond taking whatever you tell it\n> >> >> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n> >> >\n> >> > May be support git+mosh as a protocol, since it is not a drop in\n> >> > replacement. It is redesigned remote shell. The ideas it uses for\n> >> > session resumption needs to be reimplemented. This will need support\n> >> > from git, because it needs server side to be modified. Use SSP to return\n> >> > the the current progress for a particular session (it uses AES session ids).\n> >>\n> >> It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further.\n> > \n> > is that really relevent? mosh doesn't support things like X forwarding\n> > or port forwarding, but it certainly does support ssh \n> > and then doing IO.\n> \n> Ah, so mosh's README lied to me!\n\nI wouldn't say it lied, its just not really clear what is \"interactive\"\nI'd say git's use of ssh is kind of interactive compared to things like\nport forwarding.\n\n> If `mosh @ ` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it?\n\nit does work, I just tried mosh $host cat and then typing stuff and\nhaving it printed back at me. However it clears the terminal before\nhand and prints a message on exit. I tried GIT_SSH=mosh git clone and\nit failed, but I haven't really dug into why. SO I suspect this can be\nmade to work with some work on the mosh side, but I'm not sure exactly\nhow ssh and mosh are behaving differently here.\n\nTrev\n\n> \n> Ciao,\n> Johannes\n> It might not support not doing terminal emulation\n> > stuff, but that seems like a simple thing to change in principal at which\n> > point I think it would support enough of ssh's functionality its a drop\n> > in replacement as far as git is concerned. Seems to me mosh is close\n> > enough on its own its worth experimentation by someone who cares.\n> > \n> > Trev\n> > \n> >> > So when a client connect with a session id, git server side can respond\n> >> > with the current state, how many objects received in that session, and\n> >> > client can continue from where it stopped. Client also will need to\n> >> > store session information.\n> >>\n> >> No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh.\n> >>\n> >> Ciao,\n> >> Johannes\n> >> --\n> >> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> >> the body of a message to majordomo@vger.kernel.org\n> >> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at http://vger.kernel.org/majordomo-info.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"259439","messageId":"1429125944.16649.2.camel@kaarsemaker.net","threadId":"39083","inReplyTo":"31749ad9ba57ada7f9c553191ffaddb3@www.dscho.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-04-15T19:25:44Z","receivedAt":"2015-04-15T19:25:44Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On wo, 2015-04-15 at 19:46 +0200, Johannes Schindelin wrote:\n> On 2015-04-15 17:33, Trevor Saunders wrote:\n\n> > but it certainly does support ssh \n> > and then doing IO.\n> \nYes, in interactive sessions. mosh synchronizes terminal state, it\ndoesn't allow random I/O between client and server.\n\n> Ah, so mosh's README lied to me!\n> \n> If `mosh @ ` works, then a simple `GIT_SSH=mosh`\n> should work out of the box, too. Have you tried it?\n\nIt does not and cannot work. The way mosh works, is that it uses ssh to\nlog in and launch a mosh-server daemon. This daemon and the mosh client\nthen communicate via a custom UDP protocol. The SSH connection is closed\nafter the mosh-server has been launched as it is no longer needed.\n\nThe communication between the mosh client and server synchronizes\nterminal state, somewhat like what screen/tmux do.\n\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"259444","messageId":"20150415202647.GA29170@LK-Perkele-VII","threadId":"39083","inReplyTo":"552E7927.5030803@debian.org","subject":"Re: support git+mosh for unreliable connections","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2015-04-15T20:26:47Z","receivedAt":"2015-04-15T20:26:47Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:\n> \n> Q: Are the mosh principles relevant to other network applications?\n> \n> We think so. The design principles that Mosh stands for are\n> conservative: warning the user if the state being displayed is out of\n> date, serializing and checkpointing all transactions so that if there\n> are no warnings, the user knows every prior transaction has succeeded,\n> and handling expected events (like roaming from one WiFi network to\n> another) gracefully.\n> \n> Can the ideas be used to resume a pull, push or clone operation?\n> Especially serializing and checkpointing.\n\nWell, it is possible to write a remote helper and serverside program\nthat internally handles connection unreliability, so Git itself\n(upload-archive, upload-pack, receive-pack, archive, fetch-pack\nand send-pack) sees a reliable (full-duplex, half-closeable, stream)\nchannel.\n\nSuitably done, that can \"resume\" (from Git POV, nothing special\nhappened) across things like IP address changes.\n\nHowever, that is quite difficult to do in practice. Not because\ninterface to Git is complicated, but because the transport problem\nitself is complicated (however, it still seems way easier than\nmaking Git internally be able to resume interrupted operations).\n\nMosh needs to solve at least most of that, it just doesn't provode\nthe right kind of interface.\n\n\n-Ilari\n"},{"id":"259479","messageId":"552F8106.2060806@drmicha.warpmail.net","threadId":"39083","inReplyTo":"20150415185907.GC21768@tsaunders-iceball.corp.tor1.mozilla.com","subject":"Re: support git+mosh for unreliable connections","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-16T09:29:42Z","receivedAt":"2015-04-16T09:29:42Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Trevor Saunders venit, vidit, dixit 15.04.2015 20:59:\n> On Wed, Apr 15, 2015 at 07:46:15PM +0200, Johannes Schindelin wrote:\n>> Hi Trevor,\n>>\n>> On 2015-04-15 17:33, Trevor Saunders wrote:\n>>> On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:\n>>>>\n>>>> On 2015-04-15 16:18, Pirate Praveen wrote:\n>>>>> On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:\n>>>>>> What would that require git to do, beyond taking whatever you tell it\n>>>>>> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?\n>>>>>\n>>>>> May be support git+mosh as a protocol, since it is not a drop in\n>>>>> replacement. It is redesigned remote shell. The ideas it uses for\n>>>>> session resumption needs to be reimplemented. This will need support\n>>>>> from git, because it needs server side to be modified. Use SSP to return\n>>>>> the the current progress for a particular session (it uses AES session ids).\n>>>>\n>>>> It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further.\n>>>\n>>> is that really relevent? mosh doesn't support things like X forwarding\n>>> or port forwarding, but it certainly does support ssh \n>>> and then doing IO.\n>>\n>> Ah, so mosh's README lied to me!\n> \n> I wouldn't say it lied, its just not really clear what is \"interactive\"\n> I'd say git's use of ssh is kind of interactive compared to things like\n> port forwarding.\n> \n>> If `mosh @ ` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it?\n> \n> it does work, I just tried mosh $host cat and then typing stuff and\n> having it printed back at me. However it clears the terminal before\n> hand and prints a message on exit. I tried GIT_SSH=mosh git clone and\n> it failed, but I haven't really dug into why. SO I suspect this can be\n> made to work with some work on the mosh side, but I'm not sure exactly\n> how ssh and mosh are behaving differently here.\n> \n> Trev\n\nFirst thing you see on mosh.mit.edu:\n\n\"Mosh is a replacement for SSH.\"\n\nI guess that needs a footnote...\n\nMichael\n"},{"id":"259664","messageId":"5534BB5D.4000802@debian.org","threadId":"39083","inReplyTo":"20150415202647.GA29170@LK-Perkele-VII","subject":"Re: support git+mosh for unreliable connections","fromName":"Pirate Praveen","fromEmail":"praveen@debian.org","sentAt":"2015-04-20T08:39:57Z","receivedAt":"2015-04-20T08:39:57Z","isPatch":false,"sender":{"key":"praveen@debian.org","avatar":null},"body":"On Thursday 16 April 2015 01:56 AM, Ilari Liusvaara wrote:\n> On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:\n>>\n>> Q: Are the mosh principles relevant to other network applications?\n>>\n>> We think so. The design principles that Mosh stands for are\n>> conservative: warning the user if the state being displayed is out of\n>> date, serializing and checkpointing all transactions so that if there\n>> are no warnings, the user knows every prior transaction has succeeded,\n>> and handling expected events (like roaming from one WiFi network to\n>> another) gracefully.\n>>\n>> Can the ideas be used to resume a pull, push or clone operation?\n>> Especially serializing and checkpointing.\n> \n> Well, it is possible to write a remote helper and serverside program\n> that internally handles connection unreliability, so Git itself\n> (upload-archive, upload-pack, receive-pack, archive, fetch-pack\n> and send-pack) sees a reliable (full-duplex, half-closeable, stream)\n> channel.\n> \n> Suitably done, that can \"resume\" (from Git POV, nothing special\n> happened) across things like IP address changes.\n> \n> However, that is quite difficult to do in practice. Not because\n> interface to Git is complicated, but because the transport problem\n> itself is complicated (however, it still seems way easier than\n> making Git internally be able to resume interrupted operations).\n> \n> Mosh needs to solve at least most of that, it just doesn't provode\n> the right kind of interface.\n\nI have requested mosh team to fix these issues\nhttps://github.com/keithw/mosh/issues/597\n\n\n"},{"id":"259787","messageId":"20150422065405.GB11889@inner.h.apk.li","threadId":"39083","inReplyTo":"1429125944.16649.2.camel@kaarsemaker.net","subject":"Re: support git+mosh for unreliable connections","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2015-04-22T06:54:05Z","receivedAt":"2015-04-22T06:54:05Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Wed, 15 Apr 2015 21:25:44 +0000, Dennis Kaarsemaker wrote:\n...\n> It does not and cannot work. The way mosh works, is that it uses ssh to\n> log in and launch a mosh-server daemon. This daemon and the mosh client\n> then communicate via a custom UDP protocol. The SSH connection is closed\n> after the mosh-server has been launched as it is no longer needed.\n> \n> The communication between the mosh client and server synchronizes\n> terminal state, somewhat like what screen/tmux do.\n\nI object to the 'can not' part a bit. There is (1) the terminal state\nprediction and (2) the reliable-over-reconnects communication, and for\na noninteractive usage you'd need only (2).\n\nOnce upon a time I implemented a simple UDP server and client;\nthe client to be used as a ProxyCommand in ssh, and the server\njust talks to the local ssh server. This pretty much does what\nthe OP wants, and it works just as a transport for ssh, so\nall ssh features are there (but of course there is no\nterminal prediction). Unfortunately it needs to be ported\nto libev/libuv before it could be released. It's *much*\nsimpler than mosh, although the use-ssh-to-start-server\ntrick would be nice.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"}]}