[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Git ~unusable on slow lines :,'C
From:       cmn () elego ! de (Carlos =?utf-8?Q?Mart=C3=ADn?= Nieto)
Date:       2012-10-09 1:49:36
Message-ID: 87lifgct3j.fsf () centaur ! cmartin ! tk
[Download RAW message or body]

Marcel Partap <mpartap@gmx.net> writes:

> Dear Git Devs,
> I love GIT, but since a couple of months I'm on 3G and after my traffic
> limit is transcended, things slow down to a feeble 8KiB/s. Juuuust like
> back then - things moved somewhat slower. And I'm fine with that - as
> long as things just keep moving.
> Unfortunately, git does not scale down very well, so for ten more days I
> will be unable to get the newest commits onto my machine. Which is very,
> very sad :/
>> git fetch --verbose --all 
>> Fetching origin
>> POST git-upload-pack (1023 bytes)
>> POST git-upload-pack (gzip 1123 to 614 bytes)
>> POST git-upload-pack (gzip 1973 to 1030 bytes)
>> POST git-upload-pack (gzip 5173 to 2639 bytes)
>> POST git-upload-pack (gzip 7978 to 4042 bytes)
>> remote: Counting objects: 24504, done.
>> remote: Compressing objects: 100% (10705/10705), done.
>> error: RPC failed; result=56, HTTP code = 200iB | 10 KiB/s       
>> fatal: The remote end hung up unexpectedly
>> fatal: early EOF
>> fatal: index-pack failed
>> error: Could not fetch origin
> Bam, the server kicked me off after taking to long to sync my copy.

This is unrelated to git. The HTTP server's configuration is too
impatient.

> Multiple potential points of action:
> - git fetch should show the total amount of data it is about to
> transfer!

It can't, because it doesn't know.

> - when ab^H^Horting, the cursor should be moved down (tput cud1) to not
> overwrite previous output

The error message doesn't really know whether it is going to overwrite
it (the CR comes from the server), though I suppose an extra LF wouldn't
hurt there.

> - would be nice to be able to tell git fetch to get the next chunk of
> say 500 commits instead of trying to receive ALL commits, then b0rking
> after umpteen percent on server timeout. Not?

You asked for the current state of the repository, and that's what its
giving you. The timeout has nothing to do with git, if you can't
convince the admins to increase it, you can try using another transport
which doesn't suffer from HTTP, as it's most likely an anti-DoS measure.

If you want to download it bit by bit, you can tell fetch to download
particular tags. Doing this automatically for this would be working
around a configuration issue for a particular server, which is generally
better fixed in other ways.


   cmn
--
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
[prev in list] [next in list] [prev in thread] [next in thread]