threads / discuss / 35587

aborted 'git fetch' leaves workspace unusable

Subject: aborted 'git fetch' leaves workspace unusable

## tl;dr

3 messages between Dec 30, 2013 and Dec 30, 2013.

replies: 2people: 3as markdown or json

stephen_leake@stephe-leake.org· Dec 30, 2013, 17:07 UTC · lore

I forgot to do 'ssh-add', so a 'git fetch' running under Windows Emacs tried to prompt for the ssh passphrase, could not find an ssh passphrase prompt program, and aborted.

That left the workspace unusable:

- .git/FETCH_HEAD is empty

     that causes 'git rev-parse FETCH_HEAD' to fail with a confusing
     error message.

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

     even with -v --progress

A fresh clone allowed me to continue working, but this will happen again, so I'd like a better fix.

The fetch is from stephen_leake@git.savannah.gnu.org/emacs/elpa.git

I'm running git 1.7.9 from Cygwin. I have access to Debian, where I can compile git and run it under the debugger, if that helps. I have not yet tried to reproduce this bug on Debian.

-- -- Stephe

Junio C Hamano· Dec 30, 2013, 19:37 UTC · re: stephen_leake@stephe-leake.org · lore

Re: aborted 'git fetch' leaves workspace unusable

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

Torsten Bögershausen· Dec 30, 2013, 19:54 UTC · re: stephen_leake@stephe-leake.org · lore

Re: aborted 'git fetch' leaves workspace unusable

On 2013-12-30 18.07, stephen_leake@stephe-leake.org wrote:

> I forgot to do 'ssh-add', so a 'git fetch' running under Windows Emacs

Windows native emacs or emacs under cygwin ?

Show 9 quoted lines

> tried to prompt for the ssh passphrase, could not find an ssh passphrase
> prompt program, and aborted.
> 
> That left the workspace unusable:
> 
> - .git/FETCH_HEAD is empty
> 
>     that causes 'git rev-parse FETCH_HEAD' to fail with a confusing
>     error message.

Would you mind to post the "confusion error message" here? Because some people may find it useful.

Show 15 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)
> 
>     even with -v --progress
> 
> A fresh clone allowed me to continue working, but this will happen
> again, so I'd like a better fix.
> 
> The fetch is from stephen_leake@git.savannah.gnu.org/emacs/elpa.git
> 
> I'm running git 1.7.9 from Cygwin.

This feels old, we have v1.8.5.2 as the latest version.

I have access to Debian, where I can

> compile git and run it under the debugger, if that helps. I have not yet
> tried to reproduce this bug on Debian.

This could be helpful:
a) compile git under cygwin (try 1.8.5.2), and see if the problem is still there.
b) Which version of cygwin do you have? 
c) If the same problem exist under Debian, debugging it could be helpfull, yes.
  If the same problem exist here, in some version of git, it would be helpful to test
  the latest version of git. (Which means compile & debug)
HTH
/Torsten