stephen_leake@xxxxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html