cloud connection timeout

[Dirk Hohndel]

> On Mar 23, 2016, at 8:34 AM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> On Wed, Mar 23, 2016 at 8:19 AM, Dirk Hohndel <dirk at hohndel.org> 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