Re: git fetch origin hanging in 1.7.0

[Jeff King <peff@peff.net>]

On Mon, Feb 15, 2010 at 07:08:25PM -0500, Kevin Menard wrote:

> I've run into an issue that doing a "git fetch origin" is hanging for
> me in git 1.7.0.  The setup here may be wrong, so I don't want to call
> it a bug.  But basically I have an empty repo created on the server
> that a client then clones.  There's a job that fetches new updates to
> the server periodically.  If nothing has been pushed to the server
> yet, the client fetch hangs.
> 
> This worked fine in 1.6.6, so I'll just roll back my version for now.
> But any help on how to do this different would be much appreciated.

No, what you're doing should work OK (though it does actually produce
ugly "the remote end hung up unexpectedly" messages in v1.6.6).

I can reproduce the bug with:

  $ mkdir foo && (cd foo && git init)
  $ git clone foo bar
  Initialized empty Git repository in /home/peff/bar/.git/
  warning: You appear to have cloned an empty repository.
  $ cd bar && git fetch

which hangs on a pipe read(). It bisects to 61b075b (Support taking over
transports, 2009-12-09) from Ilari (cc'd). It looks like we get the
empty ref list once in get_remote_heads, and then try to get it again
and hang. Maybe we need this?

diff --git a/transport.c b/transport.c
index ad25b98..e6f9464 100644
--- a/transport.c
+++ b/transport.c
@@ -1010,7 +1010,8 @@ int transport_push(struct transport *transport,
 
 const struct ref *transport_get_remote_refs(struct transport *transport)
 {
-	if (!transport->remote_refs)
+	struct git_transport_data *data = transport->data;
+	if (!data->got_remote_heads)
 		transport->remote_refs = transport->get_refs_list(transport, 0);
 
 	return transport->remote_refs;

That fixes the problem for me, but I am totally clueless about this
code. Do all transports have a git_transport_data (if so, then why is it
a void pointer?).

-Peff