Junio C Hamano <gits...@pobox.com> writes:

stephen_le...@stephe-leake.org writes:

That left the workspace unusable:

- .git/FETCH_HEAD is empty

    that causes 'git rev-parse FETCH_HEAD' to fail with a confusing
    error message.

This is not limited to your Cygwin environment.  I can see that we
leave an empty file there after a failed fetch with

        $ git fetch ssh://no.such.place/

But I would not call it leaving "the workspace unusable".  If you
ask "git rev-parse" "What is in FETCH_HEAD?", you would get "that is
not even a revision", which is what you would get.

Yes, and I also discovered that FETCH_HEAD is not present after a clone.
So in general I need to be tolerant of an empty/missing FETCH_HEAD (I'm
actually working on an Emacs front end for git).

However, in this case, even running the fetch was a mistake; I would
have prefered that it leave FETCH_HEAD in its previous state. Is there
any way to reconstruct it? refs/heads/master was untouched, but I don't
know how to find the fetched head.

- 'git fetch' just hangs after outputting:

remote: Counting objects: 15, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 5), reused 0 (delta 0)

This looks more serious, but I suspect it is totally unrelated to
your previous fetch failing and leaving FETCH_HEAD there.  Is this
"'git fetch' hangs" reproduce in a clean clone _without_ first
encountering the failure (due to the forgotton "ssh-add")?

no, the clone worked (so the network is up, the server is up), and a
subsequent 'git fetch' did not hang. Although there was also nothing to

I'll have to wait until there is something to fetch, and see if I can
reproduce the bug. Or set up a git server and test branch - not high
enough on my priority list.

-- Stephe

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to