{"thread":{"id":"51113","subject":"Resetting files during a merge causes loss of resetted change, invisible in commit logs.","startedAt":"2019-05-17T10:28:25Z","lastAt":"2019-05-17T16:56:50Z","messageCount":2,"participants":["Thijs ter Horst","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"375796","messageId":"CAK1=Op7qo3xVo3h=GJRxxw8q68ahtis-bAPa0eTD9eJeFF8TCg@mail.gmail.com","threadId":"51113","inReplyTo":null,"subject":"Resetting files during a merge causes loss of resetted change, invisible in commit logs.","fromName":"Thijs ter Horst","fromEmail":"gmterhorst@gmail.com","sentAt":"2019-05-17T10:28:11Z","receivedAt":"2019-05-17T10:28:25Z","isPatch":false,"sender":{"key":"gmterhorst@gmail.com","avatar":null},"body":"Dear all,\n\nDisclaimer: I have never done a bug report / worked with mailing lists\nbefore, so if I'm doing things wrong I'd gladly hear.\n\nAs the title describes, git can change files without logging the\nchange. I'm not sure how to describe it shortly, so I've made a\nminimal reproduction at 'https://github.com/gmth/git_test', along with\na shell script (git_debug.sh) that reproduces what I think is a\nproblem. In that repo \"text1.txt\" changes back when according to\ncommit logs it shouldnt have.\n\nI ran into this when I lost some changes in my codebase that I could\nnot find in the commit logs, and a merge commit ('feature' into\n'master') showed that that commit reverted a file to an earlier state,\nwhile that change was not visible in any commits in 'feature'. The\ncause in my case was probably that I accidentally clicked the\n\"Discard\" button on a file in SmartGit, but the shell script shows how\nto reproduce it with commandline git. Therefore I do not think this\nhas to do with SmartGit.\n\nI am unsure if I'm allowed to attach the reproducing shell script to\nthis email, so that's why I haven't (spam filters etc).\n\nKind regards,\n\nThijs ter Horst\n"},{"id":"375805","messageId":"CABPp-BFgTi728c+2vXA8Yxi103Hfsfov69GrJKXzYv-H_wwQ7g@mail.gmail.com","threadId":"51113","inReplyTo":"CAK1=Op7qo3xVo3h=GJRxxw8q68ahtis-bAPa0eTD9eJeFF8TCg@mail.gmail.com","subject":"Re: Resetting files during a merge causes loss of resetted change, invisible in commit logs.","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-05-17T16:56:37Z","receivedAt":"2019-05-17T16:56:50Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Thijs,\n\nOn Fri, May 17, 2019 at 3:47 AM Thijs ter Horst <gmterhorst@gmail.com> wrote:\n>\n> Dear all,\n>\n> Disclaimer: I have never done a bug report / worked with mailing lists\n> before, so if I'm doing things wrong I'd gladly hear.\n>\n> As the title describes, git can change files without logging the\n> change. I'm not sure how to describe it shortly, so I've made a\n> minimal reproduction at 'https://github.com/gmth/git_test', along with\n> a shell script (git_debug.sh) that reproduces what I think is a\n> problem. In that repo \"text1.txt\" changes back when according to\n> commit logs it shouldnt have.\n>\n> I ran into this when I lost some changes in my codebase that I could\n> not find in the commit logs, and a merge commit ('feature' into\n> 'master') showed that that commit reverted a file to an earlier state,\n> while that change was not visible in any commits in 'feature'. The\n> cause in my case was probably that I accidentally clicked the\n> \"Discard\" button on a file in SmartGit, but the shell script shows how\n> to reproduce it with commandline git. Therefore I do not think this\n> has to do with SmartGit.\n>\n> I am unsure if I'm allowed to attach the reproducing shell script to\n> this email, so that's why I haven't (spam filters etc).\n\nWe tend to just like them inline, but no big deal.\n\nWhich part is unexpected for you?  Is it that the reset command will\nreset a file to an older version (maybe there's something about the\nreset documentation we need to improve?), that certain flags to the\nlog command didn't show you test1.txt (which flags?  perhaps we need\nto improve the documentation on those flags?), or was it that you knew\nthe existing log flags wouldn't show you test1.txt based on their\ndocumentation and you expected there to be some kind of flag for the\nlog command that would highlight this 'evil' merge where by 'evil' I\nmean that it differs from an automatic-merge-and-accept-conflicts and\nparticularly in an area that's not conflicted (in which case\nhttps://bugs.chromium.org/p/git/issues/detail?id=12 may be of interest\nto you)?\n\nElijah\n"}]}