RE: git reset --hard can leave modified files

["Mirochnik, Oleg V" <oleg.v.mirochnik@intel.com>]

> -----Original Message-----
> From: Torsten Bögershausen <tboegi@web.de>
> Sent: Friday, April 29, 2022 9:50 PM
> To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>
> Cc: git@vger.kernel.org
> Subject: Re: git reset --hard can leave modified files
> 
> On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:
> > Thank you for filling out a Git bug report!
> > Please answer the following questions to help us understand your issue.
> >
> > What did you do before the bug happened? (Steps to reproduce your
> > issue) git clone https://github.com/intel/llvm cd llvm git checkout
> > git-bug-reproducer git merge 38df0bd4fccd1067f3abe078d42e94c740748628
> > -m Merge1 --no-ff git merge b6b8d34554a4d85ec064463b54a27e073c42beeb
> > -m Merge2 --no-ff git reset --hard HEAD~ git status --porcelain
> >
> > What did you expect to happen? (Expected behavior) An empty output
> > from the last command
> >
> > What happened instead? (Actual behavior)  M
> > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
> >  M
> > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.e
> > xpected
> >
> > What's different between what you expected and what actually happened?
> > Obvious
> >
> > Anything else you want to add:
> > The issue is flaky. First found for v2.29.2 Multiple executions of the
> > "git reset --hard HEAD" can help.
> > 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"
> > Got max number of runs - 45. Most of the cases (63) required 5 runs. 5 cases
> did not get the issue at all.
> > V2.36.0 built from sources got similar results:
> >
> > The script:
> > (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
> >
> > Please review the rest of the bug report below.
> > You can delete any lines you don't wish to share.
> >
> >
> > [System Info]
> > git version:
> > git version 2.36.0
> > cpu: x86_64
> > no commit associated with this build
> > sizeof-long: 8
> > sizeof-size_t: 8
> > shell-path: /bin/sh
> > uname: Linux 4.18.0-193.el8.x86_64 #1 SMP Fri Mar 27 14:35:58 UTC 2020
> > x86_64 compiler info: gnuc: 4.4 libc info: glibc: 2.28 $SHELL
> > (typically, interactive shell): /bin/bash
> >
> >
> > [Enabled Hooks]
> > not run from a git repository - no hooks to show
> 
> One quesion, out of interest:
> do you have core.autocrlf=true ?

Nope.

> What does
> git config core.autocrlf
> give you ?

Nothing:
$ git config core.autocrlf
$

> The llvm repo itself has a lot of files commited with CRLF in the repo.
> 
> You can see this by running
> git ls-files --eol | grep "^i/crlf"
> 
> So my recommendation would be to set up a proper .gitatributes file in the root
> of the repo, run
> 
> git add --renormalize .
> git add .gitattributes
> git commit -m "Normalize the line endings"

AFAIK all of them CRLF files are intentional.
LLVM community decides on the stuff, we have to follow the decisions.

\r