Re: aborted 'git fetch' leaves workspace unusable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]