{"thread":{"id":"51288","subject":"Git status parse error after v.2.22.0 upgrade","startedAt":"2019-06-11T12:59:42Z","lastAt":"2019-06-25T13:25:31Z","messageCount":12,"participants":["Espen Antonsen","Johannes Schindelin","aleksandrs@ledovskis.lv","Junio C Hamano","Jeff King","SZEDER Gábor","Aleksandrs Ļedovskis","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"377006","messageId":"3bc58c33-4268-4e7c-bf1a-fe349b3cb037@www.fastmail.com","threadId":"51288","inReplyTo":null,"subject":"Git status parse error after v.2.22.0 upgrade","fromName":"Espen Antonsen","fromEmail":"espen@inspired.no","sentAt":"2019-06-11T12:58:29Z","receivedAt":"2019-06-11T12:59:42Z","isPatch":false,"sender":{"key":"espen@inspired.no","avatar":null},"body":"Seeing an error after upgrading to git v2.22.0.\n\ngit status shows “error: could not parse ‘*a commit message from 2012*’”\n\nDowngrading to v.2.21.0 does not yield this message for git status.\n\nI can only replicate this in a private repo I have so far. Unable to share the repo but can debug if you need more info.\n"},{"id":"377020","messageId":"nycvar.QRO.7.76.6.1906112127420.789@QRFXGBC-DHN364S.ybpnyqbznva","threadId":"51288","inReplyTo":"3bc58c33-4268-4e7c-bf1a-fe349b3cb037@www.fastmail.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-06-11T19:28:19Z","receivedAt":"2019-06-11T19:28:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Espen,\n\nOn Tue, 11 Jun 2019, Espen Antonsen wrote:\n\n> Seeing an error after upgrading to git v2.22.0.\n>\n> git status shows “error: could not parse ‘*a commit message from 2012*’”\n>\n> Downgrading to v.2.21.0 does not yield this message for git status.\n>\n> I can only replicate this in a private repo I have so far. Unable to\n> share the repo but can debug if you need more info.\n\nSounds like a hook gone haywire. Find out more by setting `GIT_TRACE=1`\nbefore repeating the command.\n\nCiao,\nJohannes\n"},{"id":"377060","messageId":"38b0f33a-1da1-4231-802e-ae14d9843ad2@www.fastmail.com","threadId":"51288","inReplyTo":"nycvar.QRO.7.76.6.1906112127420.789@QRFXGBC-DHN364S.ybpnyqbznva","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Espen Antonsen","fromEmail":"espen@inspired.no","sentAt":"2019-06-12T12:47:11Z","receivedAt":"2019-06-12T12:47:14Z","isPatch":false,"sender":{"key":"espen@inspired.no","avatar":null},"body":"I don't have any hooks, just the default sample scripts. GIT_TRACE doesn't show anything else.\n\nOn Tue, 11 Jun 2019, at 21:28, Johannes Schindelin wrote:\n> Hi Espen,\n> \n> On Tue, 11 Jun 2019, Espen Antonsen wrote:\n> \n> > Seeing an error after upgrading to git v2.22.0.\n> >\n> > git status shows “error: could not parse ‘*a commit message from 2012*’”\n> >\n> > Downgrading to v.2.21.0 does not yield this message for git status.\n> >\n> > I can only replicate this in a private repo I have so far. Unable to\n> > share the repo but can debug if you need more info.\n> \n> Sounds like a hook gone haywire. Find out more by setting `GIT_TRACE=1`\n> before repeating the command.\n> \n> Ciao,\n> Johannes\n>\n"},{"id":"377101","messageId":"nycvar.QRO.7.76.6.1906122046400.789@QRFXGBC-DHN364S.ybpnyqbznva","threadId":"51288","inReplyTo":"38b0f33a-1da1-4231-802e-ae14d9843ad2@www.fastmail.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-06-12T18:47:27Z","receivedAt":"2019-06-12T18:47:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Espen,\n\nOn Wed, 12 Jun 2019, Espen Antonsen wrote:\n\n> I don't have any hooks, just the default sample scripts. GIT_TRACE\n> doesn't show anything else.\n\nOkay, it was just a guess.\n\nAnd here is another guess: unless you impart with more details about your\ntest case, I guess there is little anybody else can do to help you.\n\nCiao,\nJohannes\n"},{"id":"377127","messageId":"20190613093023.GA3919@ariake.ledovskis.lv","threadId":"51288","inReplyTo":"nycvar.QRO.7.76.6.1906122046400.789@QRFXGBC-DHN364S.ybpnyqbznva","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"","fromEmail":"aleksandrs@ledovskis.lv","sentAt":"2019-06-13T09:30:23Z","receivedAt":"2019-06-13T15:46:54Z","isPatch":false,"sender":{"key":"aleksandrs@ledovskis.lv","avatar":null},"body":"Hello,\n\nManaged to repro this problem on my private repo too.\n\nBisect points to b51a0fdc3822c2ef260f6d496b6df6d33b101e8a\nHowever, I think the real culprit is 4a72486de97b5c6b0979b2b51e50c268bdb0d4f6, specifically `parse_insn_line` call.\n\nMy repo indeed contains a \".git/sequencer/todo\" file which contains references to commits long-gone (i.e., rebased).\nRenaming or deleting this file stops whines about \"error: could not parse\".\n\n--\nRegards,\nAleksandrs Ļedovskis\n\nOn Wed, Jun 12, 2019 at 08:47:27PM +0200, Johannes Schindelin wrote:\n> Hi Espen,\n> \n> On Wed, 12 Jun 2019, Espen Antonsen wrote:\n> \n> > I don't have any hooks, just the default sample scripts. GIT_TRACE\n> > doesn't show anything else.\n> \n> Okay, it was just a guess.\n> \n> And here is another guess: unless you impart with more details about your\n> test case, I guess there is little anybody else can do to help you.\n> \n> Ciao,\n> Johannes\n"},{"id":"377129","messageId":"xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com","threadId":"51288","inReplyTo":"20190613093023.GA3919@ariake.ledovskis.lv","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-06-13T16:05:16Z","receivedAt":"2019-06-13T16:05:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"aleksandrs@ledovskis.lv writes:\n\n> My repo indeed contains a \".git/sequencer/todo\" file which\n> contains references to commits long-gone (i.e., rebased).\n> Renaming or deleting this file stops whines about \"error: could\n> not parse\".\n\nInteresting.  So in short, when the repository has leftover\nsequencer state file that is not in use, \"git status parse\" thing\n(whatever it is---are you getting it when you run \"git status\"\ncommand???)---is not careful enough to notice that it does not\nmatter even if that leftover file is unusable.\n\nTwo issues \"the sequencer\" folks may want to address are\n\n (1) make the one that reads an irrelevant/stale 'todo' file more\n     careful to ignore errors in such a file;\n\n (2) make the sequencer machinery more careful to clean up after it\n     is done or it is aborted  (for example, \"git reset --hard\"\n     could remove these state files preemptively even when a rebase\n     is not in progress, I would think).\n\nI think we already had some patches toward the latter recently.\n\nThanks for a report.\n"},{"id":"377132","messageId":"20190613162432.GA12128@sigill.intra.peff.net","threadId":"51288","inReplyTo":"xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-06-13T16:24:32Z","receivedAt":"2019-06-13T16:24:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:\n\n> aleksandrs@ledovskis.lv writes:\n> \n> > My repo indeed contains a \".git/sequencer/todo\" file which\n> > contains references to commits long-gone (i.e., rebased).\n> > Renaming or deleting this file stops whines about \"error: could\n> > not parse\".\n> \n> Interesting.  So in short, when the repository has leftover\n> sequencer state file that is not in use, \"git status parse\" thing\n> (whatever it is---are you getting it when you run \"git status\"\n> command???)---is not careful enough to notice that it does not\n> matter even if that leftover file is unusable.\n> \n> Two issues \"the sequencer\" folks may want to address are\n> \n>  (1) make the one that reads an irrelevant/stale 'todo' file more\n>      careful to ignore errors in such a file;\n> \n>  (2) make the sequencer machinery more careful to clean up after it\n>      is done or it is aborted  (for example, \"git reset --hard\"\n>      could remove these state files preemptively even when a rebase\n>      is not in progress, I would think).\n> \n> I think we already had some patches toward the latter recently.\n\nMaybe I am not understanding it correctly, but do you mean in (2) that\n\"git reset --hard\" would always clear sequencer state? That seems\nundesirable to me, as I often use \"git reset\" to move the head around\nduring a rebase. (e.g., when using \"rebase -i\" to split apart I commit,\nI stop on that commit, \"git reset\" back to the parent, and then\nselectively \"add -p\" the various parts).\n\nDirection (1) seems quite sensible to me, though.\n\n-Peff\n"},{"id":"377145","messageId":"20190613165833.GD31952@szeder.dev","threadId":"51288","inReplyTo":"xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-06-13T16:58:33Z","receivedAt":"2019-06-13T16:58:40Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:\n> aleksandrs@ledovskis.lv writes:\n> \n> > My repo indeed contains a \".git/sequencer/todo\" file which\n> > contains references to commits long-gone (i.e., rebased).\n> > Renaming or deleting this file stops whines about \"error: could\n> > not parse\".\n> \n> Interesting.  So in short, when the repository has leftover\n> sequencer state file that is not in use, \"git status parse\" thing\n> (whatever it is---are you getting it when you run \"git status\"\n> command???)---is not careful enough to notice that it does not\n> matter even if that leftover file is unusable.\n> \n> Two issues \"the sequencer\" folks may want to address are\n> \n>  (1) make the one that reads an irrelevant/stale 'todo' file more\n>      careful to ignore errors in such a file;\n> \n>  (2) make the sequencer machinery more careful to clean up after it\n>      is done or it is aborted\n\nIt may or may not be related, but...  Some weeks (months?) ago I run\ninto a situation where 'git rebase' didn't clean up after itself\nfollowing a well-timed ctrl-C, and got confused to the point that not\neven a subsequent 'git rebase --abort' was able to rectify the\nsituation.\n\nSo, I wanted to rebase just a couple of commits to somewhere else, but\nmessed up the command's parameters, and it then tried to rebase a\ncouple hundred commits.  Upon noticing the unexpectedly large numbers\nin the \"Generating patches\" progress line I hit ctrl-C, and then the\naborting 'git rebase' apparently left an incomplete/corrupted\n'.git/rebase-apply/' directory behind.  Unfortunately I didn't think\nabout saving the precious corrupted state, and deleted that dir right\naway...  only saved the transcript from the terminal later:\n\n  ~/src/git (test-atexit)$ git rebase js/test-atexit \n  First, rewinding head to replay your work on top of it...\n  Generating patches: 100% (509/509), done.\n  ^C\n  ~/src/git ((42e6cb0046...)|REBASE 1/509)$ gitk js/test-atexit \n  ~/src/git ((42e6cb0046...)|REBASE 1/509)$ git rebase --abort \n  error: could not read '.git/rebase-apply/head-name': No such file or directory\n  ~/src/git ((42e6cb0046...)|REBASE 1/509)$ git reset --hard\n  HEAD is now at 42e6cb0046 git-p4: use `test_atexit` to kill the daemon\n  ~/src/git ((42e6cb0046...)|REBASE 1/509)$ rm -rf .git/re\n  rebase-apply/    rebased-patches  refs/            \n  ~/src/git ((42e6cb0046...)|REBASE 1/509)$ rm -rf .git/rebase-apply/\n  ~/src/git ((42e6cb0046...))$ git checkout -\n\n\n"},{"id":"377154","messageId":"20190613171106.GC3919@ariake.ledovskis.lv","threadId":"51288","inReplyTo":"xmqqr27xwjwj.fsf@gitster-ct.c.googlers.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Aleksandrs Ļedovskis","fromEmail":"aleksandrs@ledovskis.lv","sentAt":"2019-06-13T17:11:06Z","receivedAt":"2019-06-13T17:11:26Z","isPatch":false,"sender":{"key":"aleksandrs@ledovskis.lv","avatar":null},"body":"On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:\n> are you getting it when you run \"git status\" command???\n\nYes, the regular old porcelain `git-status(1)`.\n\n$ git status\nerror: could not parse '<<full contents of .git/sequencer/todo here>>'\nOn branch <<some-branch>>\nnothing to commit, working tree clean\n\n--\nBest,\nAleksandrs Ļedovskis\n"},{"id":"377159","messageId":"8981e6c8-eb20-fde7-2b4c-1fbf2057caef@gmail.com","threadId":"51288","inReplyTo":"20190613162432.GA12128@sigill.intra.peff.net","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-06-13T17:43:41Z","receivedAt":"2019-06-13T17:43:35Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 13/06/2019 17:24, Jeff King wrote:\n> On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:\n> \n>> aleksandrs@ledovskis.lv writes:\n>>\n>>> My repo indeed contains a \".git/sequencer/todo\" file which\n>>> contains references to commits long-gone (i.e., rebased).\n>>> Renaming or deleting this file stops whines about \"error: could\n>>> not parse\".\n\nI think this bug report is a result of\n4a72486de9 (\"fix cherry-pick/revert status after commit\", 2019-04-16)\nwhich tries to read the sequencer todo file if it is present and there\nis no CHERRY_PICK_HEAD/REVERT_HEAD. Before that if the user committed a\nconflict resolution in the middle of a sequence of picks then status\nwould forget that there was a cherry-pick in progress. It just reuses\nthe code that cherry-pick uses to parse the first todo list item which\nexpects the commits to exist.\n\n>> Interesting.  So in short, when the repository has leftover\n>> sequencer state file that is not in use, \"git status parse\" thing\n>> (whatever it is---are you getting it when you run \"git status\"\n>> command???)---is not careful enough to notice that it does not\n>> matter even if that leftover file is unusable.\n>>\n>> Two issues \"the sequencer\" folks may want to address are\n>>\n>>  (1) make the one that reads an irrelevant/stale 'todo' file more\n>>      careful to ignore errors in such a file;\n>>\n>>  (2) make the sequencer machinery more careful to clean up after it\n>>      is done or it is aborted  (for example, \"git reset --hard\"\n>>      could remove these state files preemptively even when a rebase\n>>      is not in progress, I would think).\n>>\n>> I think we already had some patches toward the latter recently.\n> \n> Maybe I am not understanding it correctly, but do you mean in (2) that\n> \"git reset --hard\" would always clear sequencer state?\n\nI think the commit Junio is referring to is\nb07d9bfd17 (\"commit/reset: try to clean up sequencer state\", 2019-04-16)\nwhich will only remove the sequencer directory if it stops after the\npick was the last one in the series. The idea is that if cherry-pick\nstops for a conflict resolution on the last pick user commits the result\ndirectly or run reset without running `cherry-pick --continue`\nafterwards the sequencer state gets cleaned up properly.\n\n> That seems\n> undesirable to me, as I often use \"git reset\" to move the head around\n> during a rebase. (e.g., when using \"rebase -i\" to split apart I commit,\n> I stop on that commit, \"git reset\" back to the parent, and then\n> selectively \"add -p\" the various parts).\n> \n> Direction (1) seems quite sensible to me, though.\n\nNow that we try harder to clean up the sequencer state I wonder if that\nwould just cover up bugs where the state has not been removed when it\nshould have been. That can lead to unpleasant problems if the user\naborts a single revert/cherry-pick when there is stale sequencer state\naround as it rewinds HEAD to the commit when the stale\ncherry-pick/revert was started as explained in the message to b07d9bfd17\n(\"commit/reset: try to clean up sequencer state\", 2019-04-16)\n\nIf we do want to do something then maybe teaching gc not to collect\ncommits listed in .git/sequencer/todo and\n.git/rebase-merge/git-rebase-todo would be useful.\n\nBest Wishes\n\nPhillip\n\n> -Peff\n> \n\n"},{"id":"377176","messageId":"20190613190037.GA27217@sigill.intra.peff.net","threadId":"51288","inReplyTo":"8981e6c8-eb20-fde7-2b4c-1fbf2057caef@gmail.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-06-13T19:00:37Z","receivedAt":"2019-06-13T19:00:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 13, 2019 at 06:43:41PM +0100, Phillip Wood wrote:\n\n> >>  (2) make the sequencer machinery more careful to clean up after it\n> >>      is done or it is aborted  (for example, \"git reset --hard\"\n> >>      could remove these state files preemptively even when a rebase\n> >>      is not in progress, I would think).\n> >>\n> >> I think we already had some patches toward the latter recently.\n> > \n> > Maybe I am not understanding it correctly, but do you mean in (2) that\n> > \"git reset --hard\" would always clear sequencer state?\n> \n> I think the commit Junio is referring to is\n> b07d9bfd17 (\"commit/reset: try to clean up sequencer state\", 2019-04-16)\n> which will only remove the sequencer directory if it stops after the\n> pick was the last one in the series. The idea is that if cherry-pick\n> stops for a conflict resolution on the last pick user commits the result\n> directly or run reset without running `cherry-pick --continue`\n> afterwards the sequencer state gets cleaned up properly.\n\nOK, that makes a lot more sense to me. It did make me wonder if doing an\n\"e\"dit on the final commit of a rebase followed by \"reset HEAD^\" would\nclear the sequencer state. But looking at that commit, this kicks in\nonly for the cherry-pick and revert cases.\n\nThanks for explaining.\n\n> If we do want to do something then maybe teaching gc not to collect\n> commits listed in .git/sequencer/todo and\n> .git/rebase-merge/git-rebase-todo would be useful.\n\nIMHO that opens up a can of worms, because the reachability rules get\nmore complicated (so for example people trying to prune away unwanted\nhistory get confused about what is still mentioning the objects). That's\na reasonable rare case. OTOH, so is mentioning commits in an ongoing\nrebase that are not still reachable from the branch you are rebasing,\nnor the HEAD reflog.\n\n-Peff\n"},{"id":"377978","messageId":"82f4aa37-51fa-4d1a-8221-d6dd37113c70@gmail.com","threadId":"51288","inReplyTo":"8981e6c8-eb20-fde7-2b4c-1fbf2057caef@gmail.com","subject":"Re: Git status parse error after v.2.22.0 upgrade","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-06-25T13:25:25Z","receivedAt":"2019-06-25T13:25:31Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 13/06/2019 18:43, Phillip Wood wrote:\n> On 13/06/2019 17:24, Jeff King wrote:\n>> On Thu, Jun 13, 2019 at 09:05:16AM -0700, Junio C Hamano wrote:\n>>>\n>>> Two issues \"the sequencer\" folks may want to address are\n>>>\n>>>   (1) make the one that reads an irrelevant/stale 'todo' file more\n>>>       careful to ignore errors in such a file;\n>>>\n>>>   (2) make the sequencer machinery more careful to clean up after it\n>>>       is done or it is aborted  (for example, \"git reset --hard\"\n>>>       could remove these state files preemptively even when a rebase\n>>>       is not in progress, I would think).\n>>>\n>>> I think we already had some patches toward the latter recently.\n>>\n>> Maybe I am not understanding it correctly, but do you mean in (2) that\n>> \"git reset --hard\" would always clear sequencer state?\n> \n> I think the commit Junio is referring to is\n> b07d9bfd17 (\"commit/reset: try to clean up sequencer state\", 2019-04-16)\n> which will only remove the sequencer directory if it stops after the\n> pick was the last one in the series. The idea is that if cherry-pick\n> stops for a conflict resolution on the last pick user commits the result\n> directly or run reset without running `cherry-pick --continue`\n> afterwards the sequencer state gets cleaned up properly.\n> \n>> That seems\n>> undesirable to me, as I often use \"git reset\" to move the head around\n>> during a rebase. (e.g., when using \"rebase -i\" to split apart I commit,\n>> I stop on that commit, \"git reset\" back to the parent, and then\n>> selectively \"add -p\" the various parts).\n>>\n>> Direction (1) seems quite sensible to me, though.\n> \n> Now that we try harder to clean up the sequencer state I wonder if that\n> would just cover up bugs where the state has not been removed when it\n> should have been.\n\nWhen I wrote that it hadn't dawned on me that if there is an error the \nstatus will not tell the user that a cherry-pick is in progress which is \nwhat we really want so they are alerted to the stale sequencer state. \nI've posted a series [1] to address this (sadly gitgitgadget wont let me \npost it on this thread).\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://public-inbox.org/git/pull.275.git.gitgitgadget@gmail.com/T/#mf57a4ab95ba907fbf2d06ec64e9b676db158eace\n\n\n> That can lead to unpleasant problems if the user\n> aborts a single revert/cherry-pick when there is stale sequencer state\n> around as it rewinds HEAD to the commit when the stale\n> cherry-pick/revert was started as explained in the message to b07d9bfd17\n> (\"commit/reset: try to clean up sequencer state\", 2019-04-16)\n> \n> If we do want to do something then maybe teaching gc not to collect\n> commits listed in .git/sequencer/todo and\n> .git/rebase-merge/git-rebase-todo would be useful.\n> \n> Best Wishes\n> \n> Phillip\n> \n>> -Peff\n>>\n> \n"}]}