Re: aborted 'git fetch' leaves workspace unusable

Junio C Hamano [off-list ref] writes:

stephen_leake@stephe-leake.org writes:

quoted

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.

quoted

- '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
fetch.

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