git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: support git+mosh for unreliable connections

From
TSTrevor Saunders <tbsaunde@tbsaunde.org>
Date
Apr 15, 2015, 15:33 UTC
Message-ID
<20150415153317.GA21768@tsaunders-iceball.corp.tor1.mozilla.com>
In-Reply-To
<0cf0485caae569a71a8bd1aa8d1033cb@www.dscho.org>
On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:
Show 14 quoted lines
> Hi Praveen,
> 
> On 2015-04-15 16:18, Pirate Praveen wrote:
> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:
> >> What would that require git to do, beyond taking whatever you tell it
> >> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?
> > 
> > May be support git+mosh as a protocol, since it is not a drop in
> > replacement. It is redesigned remote shell. The ideas it uses for
> > session resumption needs to be reimplemented. This will need support
> > from git, because it needs server side to be modified. Use SSP to return
> > the the current progress for a particular session (it uses AES session ids).
> 
> 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.

is that really relevent? mosh doesn't support things like X forwarding or port forwarding, but it certainly does support ssh <host> <command> and then doing IO. It might not support not doing terminal emulation stuff, but that seems like a simple thing to change in principal at which point I think it would support enough of ssh's functionality its a drop in replacement as far as git is concerned. Seems to me mosh is close enough on its own its worth experimentation by someone who cares.

Trev
Show 13 quoted lines
> > So when a client connect with a session id, git server side can respond
> > with the current state, how many objects received in that session, and
> > client can continue from where it stopped. Client also will need to
> > store session information.
> 
> No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh.
> 
> Ciao,
> Johannes
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 6 of 15 in “support git+mosh for unreliable connections”
  1. Pirate PraveenApr 15, 2015
  2. Dennis KaarsemakerApr 15, 2015
  3. Michael J GruberApr 15, 2015
  4. Pirate PraveenApr 15, 2015
  5. Johannes SchindelinApr 15, 2015
  6. Trevor SaundersApr 15, 2015
  7. Johannes SchindelinApr 15, 2015
  8. Trevor SaundersApr 15, 2015
  9. Michael J GruberApr 16, 2015
  10. Dennis KaarsemakerApr 15, 2015
  11. Andreas KreyApr 22, 2015
  12. Johannes SchindelinApr 15, 2015
  13. Pirate PraveenApr 15, 2015
  14. Ilari LiusvaaraApr 15, 2015
  15. Pirate PraveenApr 20, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.