Junio C Hamano writes:
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.
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
--
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
