Re: aborted 'git fetch' leaves workspace unusable

[stephen_leake@stephe-leake.org]

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

> stephen_leake@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
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