Hi,
On Mon, 14 Jan 2008, [EMAIL PROTECTED] wrote:
> Aha, we're getting somewhere...
Good!
> 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.
The CLOSE_WAIT is probably the one from "fetch"'s internal "ls-remote",
and the next one is the one supposed to bring you the new objects.
> > 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.
Good.
> > 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?
Yes!
> 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?
Yes. It seems that the number of objects you need to fetch is crucial.
The smaller, the more likely it succeeds.
> I guess this means it is a timeout of some sort. I'm not sure if that's
> fixable?
I have no idea where the timeout comes from, but if we find that, it just
might be fixable.
> Thanks for your excellent help so far, BTW.
You're welcome! It's always nice to work with responsive bug reporters
;-)
Ciao,
Dscho
