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