Hi,
On Mon, 14 Jan 2008, [EMAIL PROTECTED] wrote:
> On Jan 14, 2:38 pm, Johannes Schindelin <[EMAIL PROTECTED]>
> wrote:
> > Could you try "git pull --rebase"?
>
> Okay, I just tried that, and also tried 'git fetch'. They both give
> the same error as 'git pull'.
Thanks for trying.
> I don't know how much more efficient the git protocol is but when
> pulling over HTTP there is usually at least a couple of seconds of
> network activity to download the updates. This makes me think the
> problem is with the initial connection because I get pretty much no
> network activity (at least according to the Windows system tray network
> monitor), apart from a very short initial burst, over the git protocol.
Git protocol is much more efficient than git protocol, especially if
upstream packs from time to time (which repo.or.cz does).
> I hate to be the guy with the ridiculous problem for the simplest
> possible use case. :) I suspect this is one of those bugs that's going
> to be a nightmare to track down.
Nevertheless, this could be interesting ;-)
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.
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.
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.)
Hth,
Dscho
