> -----Original Message----- > From: Torsten Bögershausen <tboegi@xxxxxx> > Sent: Friday, April 29, 2022 9:50 PM > To: Mirochnik, Oleg V <oleg.v.mirochnik@xxxxxxxxx> > Cc: git@xxxxxxxxxxxxxxx > 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.
