{"thread":{"id":"57818","subject":"git reset --hard can leave modified files","startedAt":"2022-04-29T15:53:27Z","lastAt":"2022-05-04T15:47:45Z","messageCount":6,"participants":["Mirochnik, Oleg V","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"454618","messageId":"CY5PR11MB6089858FD6FCC971D6F216DDC6FC9@CY5PR11MB6089.namprd11.prod.outlook.com","threadId":"57818","inReplyTo":null,"subject":"git reset --hard can leave modified files","fromName":"Mirochnik, Oleg V","fromEmail":"oleg.v.mirochnik@intel.com","sentAt":"2022-04-29T15:50:59Z","receivedAt":"2022-04-29T15:53:27Z","isPatch":false,"sender":{"key":"oleg.v.mirochnik@intel.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\ngit clone https://github.com/intel/llvm\ncd llvm\ngit checkout git-bug-reproducer\ngit merge 38df0bd4fccd1067f3abe078d42e94c740748628 -m Merge1 --no-ff\ngit merge b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff\ngit reset --hard HEAD~\ngit status --porcelain\n\nWhat did you expect to happen? (Expected behavior)\nAn empty output from the last command\n\nWhat happened instead? (Actual behavior)\n M clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp\n M clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected\n\nWhat's different between what you expected and what actually happened?\nObvious\n\nAnything else you want to add:\nThe issue is flaky. First found for v2.29.2\nMultiple executions of the \"git reset --hard HEAD\" can help.\nI ran a simple script to get some numbers: 100 attempts to get and fix the issue with up to 100 runs of the \"git reset --hard HEAD\"\nGot max number of runs - 45. Most of the cases (63) required 5 runs. 5 cases did not get the issue at all.\nV2.36.0 built from sources got similar results:\n\nThe script:\n(set -e; for a in {0..99}; do echo ++++++++++++++++ a=$a; git reset --hard origin/git-bug-reproducer; git merge b2d4d67d5e34c345cb6a3cf725b2e26a15a9dfe5 -m Merge1 --no-ff; git merge b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff; git reset --hard HEAD~; for b in {1..99}; do git status --porcelain | grep . || break; git reset --hard HEAD; done; echo ++++++++ b=$b; git status --porcelain | grep . || continue; echo FAILED $a; break; done) > ../logg 2>&1\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.36.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC 2020 x86_64\ncompiler info: gnuc: 4.4\nlibc info: glibc: 2.28\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show\r"},{"id":"454671","messageId":"20220430044940.6botq23lxmpqxbel@tb-raspi4","threadId":"57818","inReplyTo":"CY5PR11MB6089858FD6FCC971D6F216DDC6FC9@CY5PR11MB6089.namprd11.prod.outlook.com","subject":"Re: git reset --hard can leave modified files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2022-04-30T04:49:40Z","receivedAt":"2022-04-30T04:49:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> git clone https://github.com/intel/llvm\n> cd llvm\n> git checkout git-bug-reproducer\n> git merge 38df0bd4fccd1067f3abe078d42e94c740748628 -m Merge1 --no-ff\n> git merge b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff\n> git reset --hard HEAD~\n> git status --porcelain\n>\n> What did you expect to happen? (Expected behavior)\n> An empty output from the last command\n>\n> What happened instead? (Actual behavior)\n>  M clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp\n>  M clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected\n>\n> What's different between what you expected and what actually happened?\n> Obvious\n>\n> Anything else you want to add:\n> The issue is flaky. First found for v2.29.2\n> Multiple executions of the \"git reset --hard HEAD\" can help.\n> I ran a simple script to get some numbers: 100 attempts to get and fix the issue with up to 100 runs of the \"git reset --hard HEAD\"\n> Got max number of runs - 45. Most of the cases (63) required 5 runs. 5 cases did not get the issue at all.\n> V2.36.0 built from sources got similar results:\n>\n> The script:\n> (set -e; for a in {0..99}; do echo ++++++++++++++++ a=$a; git reset --hard origin/git-bug-reproducer; git merge b2d4d67d5e34c345cb6a3cf725b2e26a15a9dfe5 -m Merge1 --no-ff; git merge b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff; git reset --hard HEAD~; for b in {1..99}; do git status --porcelain | grep . || break; git reset --hard HEAD; done; echo ++++++++ b=$b; git status --porcelain | grep . || continue; echo FAILED $a; break; done) > ../logg 2>&1\n>\n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n>\n>\n> [System Info]\n> git version:\n> git version 2.36.0\n> cpu: x86_64\n> no commit associated with this build\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> uname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC 2020 x86_64\n> compiler info: gnuc: 4.4\n> libc info: glibc: 2.28\n> $SHELL (typically, interactive shell): /bin/bash\n>\n>\n> [Enabled Hooks]\n> not run from a git repository - no hooks to show\n\nOne quesion, out of interest:\ndo you have core.autocrlf=true ?\nWhat does\ngit config core.autocrlf\ngive you ?\n\n\n\nThe llvm repo itself has a lot of files commited with CRLF in the repo.\n\nYou can see this by running\ngit ls-files --eol | grep \"^i/crlf\"\n\nSo my recommendation would be to set up a proper\n.gitatributes file in the root of the repo, run\n\ngit add --renormalize .\ngit add .gitattributes\ngit commit -m \"Normalize the line endings\"\n\n\n"},{"id":"454738","messageId":"CY5PR11MB608914F7E815A8EF95441BB1C6C19@CY5PR11MB6089.namprd11.prod.outlook.com","threadId":"57818","inReplyTo":"20220430044940.6botq23lxmpqxbel@tb-raspi4","subject":"RE: git reset --hard can leave modified files","fromName":"Mirochnik, Oleg V","fromEmail":"oleg.v.mirochnik@intel.com","sentAt":"2022-05-02T18:37:26Z","receivedAt":"2022-05-02T18:37:30Z","isPatch":false,"sender":{"key":"oleg.v.mirochnik@intel.com","avatar":null},"body":"> -----Original Message-----\n> From: Torsten Bögershausen <tboegi@web.de>\n> Sent: Friday, April 29, 2022 9:50 PM\n> To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>\n> Cc: git@vger.kernel.org\n> Subject: Re: git reset --hard can leave modified files\n> \n> On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:\n> > Thank you for filling out a Git bug report!\n> > Please answer the following questions to help us understand your issue.\n> >\n> > What did you do before the bug happened? (Steps to reproduce your\n> > issue) git clone https://github.com/intel/llvm cd llvm git checkout\n> > git-bug-reproducer git merge 38df0bd4fccd1067f3abe078d42e94c740748628\n> > -m Merge1 --no-ff git merge b6b8d34554a4d85ec064463b54a27e073c42beeb\n> > -m Merge2 --no-ff git reset --hard HEAD~ git status --porcelain\n> >\n> > What did you expect to happen? (Expected behavior) An empty output\n> > from the last command\n> >\n> > What happened instead? (Actual behavior)  M\n> > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp\n> >  M\n> > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.e\n> > xpected\n> >\n> > What's different between what you expected and what actually happened?\n> > Obvious\n> >\n> > Anything else you want to add:\n> > The issue is flaky. First found for v2.29.2 Multiple executions of the\n> > \"git reset --hard HEAD\" can help.\n> > I ran a simple script to get some numbers: 100 attempts to get and fix the issue\n> with up to 100 runs of the \"git reset --hard HEAD\"\n> > Got max number of runs - 45. Most of the cases (63) required 5 runs. 5 cases\n> did not get the issue at all.\n> > V2.36.0 built from sources got similar results:\n> >\n> > The script:\n> > (set -e; for a in {0..99}; do echo ++++++++++++++++ a=$a; git reset\n> > --hard origin/git-bug-reproducer; git merge\n> > b2d4d67d5e34c345cb6a3cf725b2e26a15a9dfe5 -m Merge1 --no-ff; git merge\n> > b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff; git reset\n> > --hard HEAD~; for b in {1..99}; do git status --porcelain | grep . ||\n> > break; git reset --hard HEAD; done; echo ++++++++ b=$b; git status\n> > --porcelain | grep . || continue; echo FAILED $a; break; done) >\n> > ../logg 2>&1\n> >\n> > Please review the rest of the bug report below.\n> > You can delete any lines you don't wish to share.\n> >\n> >\n> > [System Info]\n> > git version:\n> > git version 2.36.0\n> > cpu: x86_64\n> > no commit associated with this build\n> > sizeof-long: 8\n> > sizeof-size_t: 8\n> > shell-path: /bin/sh\n> > uname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC 2020\n> > x86_64 compiler info: gnuc: 4.4 libc info: glibc: 2.28 $SHELL\n> > (typically, interactive shell): /bin/bash\n> >\n> >\n> > [Enabled Hooks]\n> > not run from a git repository - no hooks to show\n> \n> One quesion, out of interest:\n> do you have core.autocrlf=true ?\n\nNope.\n\n> What does\n> git config core.autocrlf\n> give you ?\n\nNothing:\n$ git config core.autocrlf\n$\n\n> The llvm repo itself has a lot of files commited with CRLF in the repo.\n> \n> You can see this by running\n> git ls-files --eol | grep \"^i/crlf\"\n> \n> So my recommendation would be to set up a proper .gitatributes file in the root\n> of the repo, run\n> \n> git add --renormalize .\n> git add .gitattributes\n> git commit -m \"Normalize the line endings\"\n\nAFAIK all of them CRLF files are intentional.\nLLVM community decides on the stuff, we have to follow the decisions.\n\n\r"},{"id":"454745","messageId":"20220502192634.bzjfvoda2wjjxs3i@tb-raspi4","threadId":"57818","inReplyTo":"CY5PR11MB608914F7E815A8EF95441BB1C6C19@CY5PR11MB6089.namprd11.prod.outlook.com","subject":"Re: git reset --hard can leave modified files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2022-05-02T19:26:34Z","receivedAt":"2022-05-02T19:27:01Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, May 02, 2022 at 06:37:26PM +0000, Mirochnik, Oleg V wrote:\n> > -----Original Message-----\n> > From: Torsten Bögershausen <tboegi@web.de>\n> > Sent: Friday, April 29, 2022 9:50 PM\n> > To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>\n> > Cc: git@vger.kernel.org\n> > Subject: Re: git reset --hard can leave modified files\n> >\n> > On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:\n> > > Thank you for filling out a Git bug report!\n> > > Please answer the following questions to help us understand your issue.\n> > >\n> > > What did you do before the bug happened? (Steps to reproduce your\n> > > issue) git clone https://github.com/intel/llvm cd llvm git checkout\n> > > git-bug-reproducer git merge 38df0bd4fccd1067f3abe078d42e94c740748628\n> > > -m Merge1 --no-ff git merge b6b8d34554a4d85ec064463b54a27e073c42beeb\n> > > -m Merge2 --no-ff git reset --hard HEAD~ git status --porcelain\n> > >\n> > > What did you expect to happen? (Expected behavior) An empty output\n> > > from the last command\n> > >\n> > > What happened instead? (Actual behavior)  M\n> > > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp\n> > >  M\n> > > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.e\n> > > xpected\n> > >\n> > > What's different between what you expected and what actually happened?\n> > > Obvious\n> > >\n> > > Anything else you want to add:\n> > > The issue is flaky. First found for v2.29.2 Multiple executions of the\n> > > \"git reset --hard HEAD\" can help.\n> > > I ran a simple script to get some numbers: 100 attempts to get and fix the issue\n> > with up to 100 runs of the \"git reset --hard HEAD\"\n> > > Got max number of runs - 45. Most of the cases (63) required 5 runs. 5 cases\n> > did not get the issue at all.\n> > > V2.36.0 built from sources got similar results:\n> > >\n> > > The script:\n> > > (set -e; for a in {0..99}; do echo ++++++++++++++++ a=$a; git reset\n> > > --hard origin/git-bug-reproducer; git merge\n> > > b2d4d67d5e34c345cb6a3cf725b2e26a15a9dfe5 -m Merge1 --no-ff; git merge\n> > > b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-ff; git reset\n> > > --hard HEAD~; for b in {1..99}; do git status --porcelain | grep . ||\n> > > break; git reset --hard HEAD; done; echo ++++++++ b=$b; git status\n> > > --porcelain | grep . || continue; echo FAILED $a; break; done) >\n> > > ../logg 2>&1\n> > >\n> > > Please review the rest of the bug report below.\n> > > You can delete any lines you don't wish to share.\n> > >\n> > >\n> > > [System Info]\n> > > git version:\n> > > git version 2.36.0\n> > > cpu: x86_64\n> > > no commit associated with this build\n> > > sizeof-long: 8\n> > > sizeof-size_t: 8\n> > > shell-path: /bin/sh\n> > > uname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC 2020\n> > > x86_64 compiler info: gnuc: 4.4 libc info: glibc: 2.28 $SHELL\n> > > (typically, interactive shell): /bin/bash\n> > >\n> > >\n> > > [Enabled Hooks]\n> > > not run from a git repository - no hooks to show\n> >\n> > One quesion, out of interest:\n> > do you have core.autocrlf=true ?\n>\n> Nope.\n>\n> > What does\n> > git config core.autocrlf\n> > give you ?\n>\n> Nothing:\n> $ git config core.autocrlf\n> $\n>\n> > The llvm repo itself has a lot of files commited with CRLF in the repo.\n> >\n> > You can see this by running\n> > git ls-files --eol | grep \"^i/crlf\"\n> >\n> > So my recommendation would be to set up a proper .gitatributes file in the root\n> > of the repo, run\n> >\n> > git add --renormalize .\n> > git add .gitattributes\n> > git commit -m \"Normalize the line endings\"\n>\n> AFAIK all of them CRLF files are intentional.\n> LLVM community decides on the stuff, we have to follow the decisions.\n>\n\nI somewhat suspect seriously that the problem is related to this thread:\nhttps://reviews.llvm.org/D124563\n\nI didn't dig into all the details (yet).\n\n===================================\n git show c9a16e8c3d99173c7525e576d78eed571\nDrop '* text=auto' from .gitattributes and normalize\n\n Git wants to check in 'text' files with LF endings, so this changes them\n     in the repository but not in the checkout, where they keep CRLF endings.\n\n    Differential Revision: https://reviews.llvm.org/D124563\n--------------------\nI don't know, if this was a good change or not.\nIf folks wants CRLF in their working tree, there are 3 ways to do so:\n- Set core.autoclrf to true\n- Set core.eol to CRLF\n(This works on Windows and Unix)\n\nOr, if everybody should have CRLF in the working tree,\nwe could (and should) still have LF in the repo.\n\nJust set\n\n*myfiles.cpp text=auto eol=crlf\n\nIn other words\n(I may be wrong due a lack of time to dig deeper into the llvm repo)\nthe problem seems to come from upstream.\n\nAnd we could find out, what upstream really wants and needs,\nand may be able to help here.\n\nIs this maybe something you can do, contact upstream ?\n\n"},{"id":"454751","messageId":"CY5PR11MB608955D3020A85983471A260C6C19@CY5PR11MB6089.namprd11.prod.outlook.com","threadId":"57818","inReplyTo":"20220502192634.bzjfvoda2wjjxs3i@tb-raspi4","subject":"RE: git reset --hard can leave modified files","fromName":"Mirochnik, Oleg V","fromEmail":"oleg.v.mirochnik@intel.com","sentAt":"2022-05-02T22:07:11Z","receivedAt":"2022-05-02T22:07:47Z","isPatch":false,"sender":{"key":"oleg.v.mirochnik@intel.com","avatar":null},"body":"> -----Original Message-----\n> From: Torsten Bögershausen <tboegi@web.de>\n> Sent: Monday, May 2, 2022 12:27 PM\n> To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>\n> Cc: git@vger.kernel.org\n> Subject: Re: git reset --hard can leave modified files\n> \n> On Mon, May 02, 2022 at 06:37:26PM +0000, Mirochnik, Oleg V wrote:\n> > > -----Original Message-----\n> > > From: Torsten Bögershausen <tboegi@web.de>\n> > > Sent: Friday, April 29, 2022 9:50 PM\n> > > To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>\n> > > Cc: git@vger.kernel.org\n> > > Subject: Re: git reset --hard can leave modified files\n> > >\n> > > On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:\n> > > > Thank you for filling out a Git bug report!\n> > > > Please answer the following questions to help us understand your issue.\n> > > >\n> > > > What did you do before the bug happened? (Steps to reproduce your\n> > > > issue) git clone https://github.com/intel/llvm cd llvm git\n> > > > checkout git-bug-reproducer git merge\n> > > > 38df0bd4fccd1067f3abe078d42e94c740748628\n> > > > -m Merge1 --no-ff git merge\n> > > > b6b8d34554a4d85ec064463b54a27e073c42beeb\n> > > > -m Merge2 --no-ff git reset --hard HEAD~ git status --porcelain\n> > > >\n> > > > What did you expect to happen? (Expected behavior) An empty output\n> > > > from the last command\n> > > >\n> > > > What happened instead? (Actual behavior)  M\n> > > > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.c\n> > > > pp\n> > > >  M\n> > > > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.c\n> > > > pp.e\n> > > > xpected\n> > > >\n> > > > What's different between what you expected and what actually happened?\n> > > > Obvious\n> > > >\n> > > > Anything else you want to add:\n> > > > The issue is flaky. First found for v2.29.2 Multiple executions of\n> > > > the \"git reset --hard HEAD\" can help.\n> > > > I ran a simple script to get some numbers: 100 attempts to get and\n> > > > fix the issue\n> > > with up to 100 runs of the \"git reset --hard HEAD\"\n> > > > Got max number of runs - 45. Most of the cases (63) required 5\n> > > > runs. 5 cases\n> > > did not get the issue at all.\n> > > > V2.36.0 built from sources got similar results:\n> > > >\n> > > > The script:\n> > > > (set -e; for a in {0..99}; do echo ++++++++++++++++ a=$a; git\n> > > > reset --hard origin/git-bug-reproducer; git merge\n> > > > b2d4d67d5e34c345cb6a3cf725b2e26a15a9dfe5 -m Merge1 --no-ff; git\n> > > > merge b6b8d34554a4d85ec064463b54a27e073c42beeb -m Merge2 --no-\n> ff;\n> > > > git reset --hard HEAD~; for b in {1..99}; do git status\n> > > > --porcelain | grep . || break; git reset --hard HEAD; done; echo\n> > > > ++++++++ b=$b; git status --porcelain | grep . || continue; echo\n> > > > FAILED $a; break; done) > ../logg 2>&1\n> > > >\n> > > > Please review the rest of the bug report below.\n> > > > You can delete any lines you don't wish to share.\n> > > >\n> > > >\n> > > > [System Info]\n> > > > git version:\n> > > > git version 2.36.0\n> > > > cpu: x86_64\n> > > > no commit associated with this build\n> > > > sizeof-long: 8\n> > > > sizeof-size_t: 8\n> > > > shell-path: /bin/sh\n> > > > uname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC\n> > > > 2020\n> > > > x86_64 compiler info: gnuc: 4.4 libc info: glibc: 2.28 $SHELL\n> > > > (typically, interactive shell): /bin/bash\n> > > >\n> > > >\n> > > > [Enabled Hooks]\n> > > > not run from a git repository - no hooks to show\n> > >\n> > > One quesion, out of interest:\n> > > do you have core.autocrlf=true ?\n> >\n> > Nope.\n> >\n> > > What does\n> > > git config core.autocrlf\n> > > give you ?\n> >\n> > Nothing:\n> > $ git config core.autocrlf\n> > $\n> >\n> > > The llvm repo itself has a lot of files commited with CRLF in the repo.\n> > >\n> > > You can see this by running\n> > > git ls-files --eol | grep \"^i/crlf\"\n> > >\n> > > So my recommendation would be to set up a proper .gitatributes file\n> > > in the root of the repo, run\n> > >\n> > > git add --renormalize .\n> > > git add .gitattributes\n> > > git commit -m \"Normalize the line endings\"\n> >\n> > AFAIK all of them CRLF files are intentional.\n> > LLVM community decides on the stuff, we have to follow the decisions.\n> >\n> \n> I somewhat suspect seriously that the problem is related to this thread:\n> https://reviews.llvm.org/D124563\n> \n> I didn't dig into all the details (yet).\n> \n> ===================================\n>  git show c9a16e8c3d99173c7525e576d78eed571 Drop '* text=auto' from\n> .gitattributes and normalize\n> \n>  Git wants to check in 'text' files with LF endings, so this changes them\n>      in the repository but not in the checkout, where they keep CRLF endings.\n> \n>     Differential Revision: https://reviews.llvm.org/D124563\n> --------------------\n> I don't know, if this was a good change or not.\n> If folks wants CRLF in their working tree, there are 3 ways to do so:\n> - Set core.autoclrf to true\n> - Set core.eol to CRLF\n> (This works on Windows and Unix)\n> \n> Or, if everybody should have CRLF in the working tree, we could (and should) still\n> have LF in the repo.\n> \n> Just set\n> \n> *myfiles.cpp text=auto eol=crlf\n> \n> In other words\n> (I may be wrong due a lack of time to dig deeper into the llvm repo) the problem\n> seems to come from upstream.\n> \n> And we could find out, what upstream really wants and needs, and may be able\n> to help here.\n> \n> Is this maybe something you can do, contact upstream ?\nNo, I could not as I'm not a llvm contributor.\nHere is another related discussion, hopefully could be useful -- https://reviews.llvm.org/D48494\n\nActually, I don't quite understand what your suggestions are.\n\nAre you telling it's not a git bug but an invalid setup in the llvm-project repo?\nIf so, then I'd suggest you (or git community) provide a clear description (or link to a related document) what needs to be done to make it valid and I'd ask one of our contributors to propose a correspondent fix into the upstream.\nOr you agree it's a bug.\nThen I'd ask to propose your recommendations as a temporary (or permanent) workaround.\n\nCould you please clarify?\n\r"},{"id":"454826","messageId":"20220504154228.wxk6scaqtzri5w42@tb-raspi4","threadId":"57818","inReplyTo":"CY5PR11MB608955D3020A85983471A260C6C19@CY5PR11MB6089.namprd11.prod.outlook.com","subject":"Re: git reset --hard can leave modified files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2022-05-04T15:42:28Z","receivedAt":"2022-05-04T15:47:45Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, May 02, 2022 at 10:07:11PM +0000, Mirochnik, Oleg V wrote:\n[]\n> >\n> > In other words\n> > (I may be wrong due a lack of time to dig deeper into the llvm repo) the problem\n> > seems to come from upstream.\n> >\n> > And we could find out, what upstream really wants and needs, and may be able\n> > to help here.\n> >\n> > Is this maybe something you can do, contact upstream ?\n> No, I could not as I'm not a llvm contributor.\nYou can become one ;-)\n\n> Here is another related discussion, hopefully could be useful -- https://reviews.llvm.org/D48494\n>\n> Actually, I don't quite understand what your suggestions are.\n>\n> Are you telling it's not a git bug but an invalid setup in the llvm-project repo?\nYes\n\n> If so, then I'd suggest you (or git community) provide a clear description\n> (or link to a related document) what needs to be done to make it valid\n> and I'd ask one of our contributors to propose a correspondent fix into the upstream.\n> Or you agree it's a bug.\n> Then I'd ask to propose your recommendations as a temporary (or permanent) workaround.\n>\n> Could you please clarify?\n\nNow, the documentation, which I think you ask for, is here:\nhttps://git-scm.com/docs/gitattributes\n\nIf I look at the repo, commit 4ff40855fcc0c1320f31350bc9e93d4d6ce6891f\n(HEAD -> git-bug-reproducer, origin/git-bug-reproducer)\n\nand run the official eol-diagnostic tool:\n$ git ls-files --eol >eol-prob.txt\nand then\n$ grep \"^i/crlf.*attr/text\" eol-prob.txt\nI get 9 files listed, so I pick the first one for a discussion:\n\ni/crlf  w/crlf  attr/text eol=crlf      clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp\n\nWhat we have in the repo is a \"conflict\".\nThe attributes says it is a text file, and the index file (what had been commited)\nhas CRLF.\nGit can not resolve the conflict.\n(setting text=auto could work. Or normalize. Or both. Normalization is recomended anyway)\n\nSo, the solution would be to renormalize all files:\n\n$ git add --renormalize .\n(The . is important)\n\nAfter that you will see those 9 files modified, and they need to be commited.\n\nIn general, for a cross-platform project, it could be useful to set up a\n.gitattributes file in the top directory, with one line:\n* text=auto\n\nThat file can then be tweaked for BAT or sh files as needed.\n\nThat should all be in the documentation - if not, please ask and/or send us\npatches.\n\n\n\n\n\n\n\n"}]}