Aha, we're getting somewhere...
On Jan 14, 4:03 pm, Johannes Schindelin <[EMAIL PROTECTED]>
wrote:
> Could you make sure (I would use "netstat -a") that the connection
> actually succeeded? Other than that, it might boil down to network issues
> such as timeout of your router, or some problems with packet sizes.
Netstat shows two connections related to git during the 'git pull',
one with CLOSE_WAIT and the other with ESTABLISHED.
I'm not too familiar with netstat I'm afraid so I don't know if the
two connections make any sense, however...
> A quick test towards the theory of timeouts would be to start by "git
> ls-remote origin", which uses exactly the same protocol as "fetch", but
> exits early.
Yes! This works.
> If that succeeds, you could try with a fresh clone, by "git reset --hard
> HEAD^ && rm .git/refs/remotes/origin/{HEAD,master}". (I would try this on
> a tiny repository, such as git-cheetah.)
If I understand correctly, this command deletes the latest changeset
so I don't have to wait for new changes on the remote end?
What I did was:
1. git clone git://repo.or.cz/git-cheetah.git
2. git reset --hard HEAD^ && rm .git/refs/remotes/origin/{HEAD,master}
3. git pull
And it worked! Is that what you intended?
I guess this means it is a timeout of some sort. I'm not sure if
that's fixable?
Thanks for your excellent help so far, BTW.
