On Thu, Nov 22, 2012 at 10:39 AM, Yichao Yu <yyc1992@xxxxxxxxx> wrote: > I sent this email yesterday to the git mailing list but I cannot find > it in any archive so I decide to send it again. If it was HTML formatted it would have been silently dropped by the list. > Does anyone know what has happened to the mailing list? I haven't > receive any email from several kernel related busy mailing lists for > several hours.... US holiday today? The list traffic tends to be down during holidays. > I want to build packages for snap shoot of different branches from > different remote git repositories in the same local directory (so that > I don't need to recompile everything everytime.) and I am using a > combination of `git clone/checkout/reset/fetch` to do that. However, > during git-fetch, the remote sometimes stop responding or simply reset > the connection. This happens occasionally at least for both ssh and > git protocol (not sure about http/https) on github, bitbucket and also > kernel.org so I think it is probably not due to a weird behavior of a > certain host. Does anyone know the reason or is there anything I have > done wrong? And is there a better way to set the local tree to a > certain branch at a certain url? THX If the remote server is really busy it might be OOM'ing the server process which would disconnect the client. Or maybe its your ISP sending a rogue RST packet to kill the connection because they don't like traffic that leaves their network and costs them money on a peering agreement. Or... ? > #!/bin/bash > > repo_name=git > # remote1='git://github.com/torvalds/linux.git' > remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git' > branch1='master' > # remote2='git://github.com/git/git.git' > remote2='git://git.kernel.org/pub/scm/git/git.git' > branch2='next' > > git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name" > cd "$repo_name" > git fetch -vvv "$remote2" # "$branch2:$branch2" > > ----------------------------------------------- > > Cloning into 'git'... > remote: Counting objects: 43215, done. > remote: Compressing objects: 100% (41422/41422), done. > remote: Total 43215 (delta 3079), reused 22032 (delta 1247) > Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done. > Resolving deltas: 100% (3079/3079), done. > Checking out files: 100% (40905/40905), done. > fatal: destination path 'git' already exists and is not an empty directory. Why does this error come up? It looks like git already exists locally. Git should have aborted much earlier in clone when the directory exists. > Server supports multi_ack_detailed > Server supports side-band-64k > Server supports ofs-delta > want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD) > have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386 > have db9d8c60266a5010e905829e10cd722519e14777 > done > fatal: The remote end hung up unexpectedly This looks like its from the fetch command. Since the server doesn't report any errors to the client, its hard to say why the server just gave up right there. I wonder if this is related to the fact that you did a shallow clone initially. The shallow clone may have confused the server when fetch ran because it only sent 2 have lines and gave up. Try exporting GIT_TRACE_PACKET=1 and seeing if you can get more detailed information from the protocol on the client side. FYI, https://kernel.googlesource.com/ mirrors git://git.kernel.org/ so you can also try pulling from that server (e.g. https://kernel.googlesource.com/pub/scm/git/git.git). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html