> On Mar 23, 2016, at 8:34 AM, Linus Torvalds <[email protected]> > wrote: > > On Wed, Mar 23, 2016 at 8:19 AM, Dirk Hohndel <[email protected]> wrote: >> >> Yes, git gives us a very vague idea of how big the transfer might be, but >> that's long after the SSL connection was established. And Miika never gets >> that far because we have a fairly short timeout for the SSL connection. > > Also, on a bad connection it tends to be the initial handshakes where > git tries to figure out what to transfer that is the worst part. > That's the latency-sensitive part of the transfer where the client and > server do some back-and-forth discussion. If you don't have pictures > in your git repository, the actual bulk data transfter itself should > stream well, and not be too expensive. > > I also would not be surprised if that the initial handshake might be > the weakest part of libgit2. We've certainly encountered situations > where libgit2 doesn't do as well as "real" git, because the library > implementation made a few code simplifications. > > But in this case it sounds like we're not even getting to that git > handshake part, and are failing even before that just in the ssh > setup.
it's https / SSL setup where we are failing... cloud storage doesn't use ssh as transport layer. But other than that irrelevant detail I think you are spot on correct /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
