1 |
On 17/01/14 00:38, Walter Dnes wrote: |
2 |
> On Thu, Jan 16, 2014 at 01:14:28PM +0200, Nikos Chantziaras wrote |
3 |
>> With overlays.gentoo.org being down, by update script takes a long time |
4 |
>> to complete. Instead of Git telling me immediately that it can't connect |
5 |
>> to the server, it just sits there for whole minutes doing nothing before |
6 |
>> it decides to abort. |
7 |
>> |
8 |
>> This is extremely frustrating. Is there a way to change this behavior of |
9 |
>> Git? Other software doesn't seem to have this problem (for example if I |
10 |
>> browse to a web server that's down, the browser immediately tells me |
11 |
>> that it can't connect, rather going for a coffee break first.) |
12 |
> |
13 |
> Unfortunately, the git client itself can't do this, due to "keepalive" |
14 |
> code built into git. See |
15 |
> http://git.661346.n2.nabble.com/Request-timeout-option-for-remote-operations-esp-quot-git-fetch-quot-td7598943.html |
16 |
> |
17 |
> About the only thing you can do is use the "timeout" command to launch |
18 |
> git as a subcommand, e.g. |
19 |
> |
20 |
> timeout 1m git fetch |
21 |
> |
22 |
> The downside of this approach is that if the git server is feeding |
23 |
> data very slowly, your git client gets killed after the time limit, even |
24 |
> if it's 90% of the way through the download. |
25 |
|
26 |
This is weird. How can you "keep alive" something that's dead from the |
27 |
beginning? :-/ AFAIK, "keep alive" in networking refers to keeping an |
28 |
active connection alive. Here, a connection can't even be established in |
29 |
the first place. The server is down. |