{"thread":{"id":"35590","subject":"Re: aborted 'git fetch' leaves workspace unusable","startedAt":"2013-12-31T08:19:25Z","lastAt":"2014-01-03T17:58:43Z","messageCount":4,"participants":["stephen_leake@stephe-leake.org","Junio C Hamano","Stephen Leake"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"232539","messageId":"32eeea08963ec4438f97ff9ef6553a75@stephe-leake.org","threadId":"35590","inReplyTo":null,"subject":"Re: aborted 'git fetch' leaves workspace unusable","fromName":"","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2013-12-31T08:19:25Z","receivedAt":"2013-12-31T08:19:25Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> stephen_leake@stephe-leake.org writes:\n> \n>> That left the workspace unusable:\n>> \n>> - .git/FETCH_HEAD is empty\n>> \n>> that causes 'git rev-parse FETCH_HEAD' to fail with a confusing\n>> error message.\n> \n> This is not limited to your Cygwin environment. I can see that we\n> leave an empty file there after a failed fetch with\n> \n> \t$ git fetch ssh://no.such.place/\n> \n> But I would not call it leaving \"the workspace unusable\". If you\n> ask \"git rev-parse\" \"What is in FETCH_HEAD?\", you would get \"that is\n> not even a revision\", which is what you would get.\n\nYes, and I also discovered that FETCH_HEAD is not present after a \nclone.\nSo in general I need to be tolerant of an empty/missing FETCH_HEAD (I'm\nactually working on an Emacs front end for git).\n\nHowever, in this case, even running the fetch was a mistake; I would\nhave prefered that it leave FETCH_HEAD in its previous state. Is there\nany way to reconstruct it? refs/heads/master was untouched, but I don't\nknow how to find the fetched head.\n\n>> - 'git fetch' just hangs after outputting:\n>> \n>> remote: Counting objects: 15, done.\n>> remote: Compressing objects: 100% (8/8), done.\n>> remote: Total 9 (delta 5), reused 0 (delta 0)\n> \n> This looks more serious, but I suspect it is totally unrelated to\n> your previous fetch failing and leaving FETCH_HEAD there. Is this\n> \"'git fetch' hangs\" reproduce in a clean clone _without_ first\n> encountering the failure (due to the forgotton \"ssh-add\")?\n\nno, the clone worked (so the network is up, the server is up), and a\nsubsequent 'git fetch' did not hang. Although there was also nothing to\nfetch.\n\nI'll have to wait until there is something to fetch, and see if I can\nreproduce the bug. Or set up a git server and test branch - not high\nenough on my priority list.\n\n--\n-- Stephe\n"},{"id":"232565","messageId":"xmqqbnzuqmqe.fsf@gitster.dls.corp.google.com","threadId":"35590","inReplyTo":"32eeea08963ec4438f97ff9ef6553a75@stephe-leake.org","subject":"Re: aborted 'git fetch' leaves workspace unusable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-02T18:09:45Z","receivedAt":"2014-01-02T18:09:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"stephen_leake@stephe-leake.org writes:\n\n> However, in this case, even running the fetch was a mistake; I would\n> have prefered that it leave FETCH_HEAD in its previous state.\n\nI think the clearing of leftover FETCH_HEAD is one of the early\nthings \"git fetch\" does, unless \"--append\" is in effect. I haven't\nlooked at the code for a long time, but it may be possible to move\nthe logic of doing so around so that this clearing is done as lazily\nas possible.\n\nI however suspect that such a change may have fallouts on other\npeople who are writing tools like yours; they may be depending on\nseeing FETCH_HEAD cleared after a failed fetch, and be surprised to\nsee a stale contents after they (attempt to) run \"git fetch\" in it.\n\nSo it is not so clear if it is a good thing to change the behaviour\nof \"git fetch\" not to touch FETCH_HEAD upon a failure.\n"},{"id":"232606","messageId":"85iou13fse.fsf@stephe-leake.org","threadId":"35590","inReplyTo":"xmqqbnzuqmqe.fsf@gitster.dls.corp.google.com","subject":"Re: aborted 'git fetch' leaves workspace unusable","fromName":"Stephen Leake","fromEmail":"stephen_leake@stephe-leake.org","sentAt":"2014-01-03T03:28:17Z","receivedAt":"2014-01-03T03:28:17Z","isPatch":false,"sender":{"key":"stephen_leake@stephe-leake.org","avatar":null},"body":"Junio C Hamano writes:\n\n> stephen_leake@stephe-leake.org writes:\n>\n>> However, in this case, even running the fetch was a mistake; I would\n>> have prefered that it leave FETCH_HEAD in its previous state.\n>\n> I think the clearing of leftover FETCH_HEAD is one of the early\n> things \"git fetch\" does, unless \"--append\" is in effect. I haven't\n> looked at the code for a long time, but it may be possible to move\n> the logic of doing so around so that this clearing is done as lazily\n> as possible.\n>\n> I however suspect that such a change may have fallouts on other\n> people who are writing tools like yours; they may be depending on\n> seeing FETCH_HEAD cleared after a failed fetch, and be surprised to\n> see a stale contents after they (attempt to) run \"git fetch\" in it.\n>\n> So it is not so clear if it is a good thing to change the behaviour\n> of \"git fetch\" not to touch FETCH_HEAD upon a failure.\n\nOk; backwards compatibility is important.\n\nPerhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to\nallow recovering in an error case?\n\n-- \n-- Stephe\n"},{"id":"232621","messageId":"xmqqsit5lzfw.fsf@gitster.dls.corp.google.com","threadId":"35590","inReplyTo":"85iou13fse.fsf@stephe-leake.org","subject":"Re: aborted 'git fetch' leaves workspace unusable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-03T17:58:43Z","receivedAt":"2014-01-03T17:58:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Leake writes:\n\n> Junio C Hamano writes:\n>\n>> stephen_leake@stephe-leake.org writes:\n>>\n>>> However, in this case, even running the fetch was a mistake; I would\n>>> have prefered that it leave FETCH_HEAD in its previous state.\n>>\n>> I think the clearing of leftover FETCH_HEAD is one of the early\n>> things \"git fetch\" does, unless \"--append\" is in effect. I haven't\n>> looked at the code for a long time, but it may be possible to move\n>> the logic of doing so around so that this clearing is done as lazily\n>> as possible.\n>>\n>> I however suspect that such a change may have fallouts on other\n>> people who are writing tools like yours; they may be depending on\n>> seeing FETCH_HEAD cleared after a failed fetch, and be surprised to\n>> see a stale contents after they (attempt to) run \"git fetch\" in it.\n>>\n>> So it is not so clear if it is a good thing to change the behaviour\n>> of \"git fetch\" not to touch FETCH_HEAD upon a failure.\n>\n> Ok; backwards compatibility is important.\n>\n> Perhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to\n> allow recovering in an error case?\n\nAs FETCH_HEAD is purely ephemeral (so are other ephemeral markers\nlike MERGE_HEAD and friends), and the promise between \"git fetch\"\nand its users has always been that an invocation of \"git fetch\"\nclears FETCH_HEAD (logical consequence of which is that the user\nruns \"git fetch\" only when s/he are _done_ with the old FETCH_HEAD),\nI doubt FETCH_HEAD_prev would add much value to the system and only\nintroduce more things we have to worry about, like \"when will it be\ncleaned?\", \"what happens to the old value in FETCH_HEAD_prev?\".\n\nIt is like asking \"Should 'rm -f foo' save the original 'foo' to\nsomewhere else just in case?\".\n\nIf your emacs wrapper for some reason needs to know what happened in\nthe last fetch, I imagine that it can check and record what was in\nFETCH_HEAD before issuing \"git fetch\", so...\n"}]}