Re: aborted 'git fetch' leaves workspace unusable

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 30, 2013, 19:37 UTC
Message-ID: <xmqq8uv2ruyy.fsf@gitster.dls.corp.google.com>
In-Reply-To: <7adcf8024c435b9b7178b86f01e447bb@stephe-leake.org>

stephen_leake@stephe-leake.org writes:

Show 6 quoted lines

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

Similar operations that try to use FETCH_HEAD as if there is a valid revision, e.g. "git merge FETCH_HEAD", would also not work, which is very much expected. I wouldn't think that needs something drastic as "this workspace is unusable, let's start from a new clone".

If it really bothers you, you can always safely do

	$ rm -f .git/FETCH_HEAD

but of course, after that, nothing that tries to use FETCH_HEAD as if there is a valid revision, e.g. "git show FETCH_HEAD", would not work until you fetch from somewhere, so there isn't that much to be gained by doing so.

Show 5 quoted lines

> - '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")?