Re: aborted 'git fetch' leaves workspace unusable
Stephen Leake stephen_le...@stephe-leake.org writes: Junio C Hamano gits...@pobox.com writes: stephen_le...@stephe-leake.org writes: However, in this case, even running the fetch was a mistake; I would have prefered that it leave FETCH_HEAD in its previous state. I think the clearing of leftover FETCH_HEAD is one of the early things git fetch does, unless --append is in effect. I haven't looked at the code for a long time, but it may be possible to move the logic of doing so around so that this clearing is done as lazily as possible. I however suspect that such a change may have fallouts on other people who are writing tools like yours; they may be depending on seeing FETCH_HEAD cleared after a failed fetch, and be surprised to see a stale contents after they (attempt to) run git fetch in it. So it is not so clear if it is a good thing to change the behaviour of git fetch not to touch FETCH_HEAD upon a failure. Ok; backwards compatibility is important. Perhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to allow recovering in an error case? As FETCH_HEAD is purely ephemeral (so are other ephemeral markers like MERGE_HEAD and friends), and the promise between git fetch and its users has always been that an invocation of git fetch clears FETCH_HEAD (logical consequence of which is that the user runs git fetch only when s/he are _done_ with the old FETCH_HEAD), I doubt FETCH_HEAD_prev would add much value to the system and only introduce more things we have to worry about, like when will it be cleaned?, what happens to the old value in FETCH_HEAD_prev?. It is like asking Should 'rm -f foo' save the original 'foo' to somewhere else just in case?. If your emacs wrapper for some reason needs to know what happened in the last fetch, I imagine that it can check and record what was in FETCH_HEAD before issuing git fetch, so... -- 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
Re: aborted 'git fetch' leaves workspace unusable
Junio C Hamano gits...@pobox.com writes: stephen_le...@stephe-leake.org writes: However, in this case, even running the fetch was a mistake; I would have prefered that it leave FETCH_HEAD in its previous state. I think the clearing of leftover FETCH_HEAD is one of the early things git fetch does, unless --append is in effect. I haven't looked at the code for a long time, but it may be possible to move the logic of doing so around so that this clearing is done as lazily as possible. I however suspect that such a change may have fallouts on other people who are writing tools like yours; they may be depending on seeing FETCH_HEAD cleared after a failed fetch, and be surprised to see a stale contents after they (attempt to) run git fetch in it. So it is not so clear if it is a good thing to change the behaviour of git fetch not to touch FETCH_HEAD upon a failure. Ok; backwards compatibility is important. Perhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to allow recovering in an error case? -- -- 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
Re: aborted 'git fetch' leaves workspace unusable
Junio C Hamano gits...@pobox.com 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
Re: aborted 'git fetch' leaves workspace unusable
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
Re: aborted 'git fetch' leaves workspace unusable
On 2013-12-30 18.07, stephen_le...@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 ? 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. - '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_le...@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 -- 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
