> -----Original Message----- > From: Torsten Bögershausen <tboegi@xxxxxx> > Sent: Monday, May 2, 2022 12:27 PM > To: Mirochnik, Oleg V <oleg.v.mirochnik@xxxxxxxxx> > Cc: git@xxxxxxxxxxxxxxx > Subject: Re: git reset --hard can leave modified files > > On Mon, May 02, 2022 at 06:37:26PM +0000, Mirochnik, Oleg V wrote: > > > -----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.c > > > > pp > > > > M > > > > clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.c > > > > pp.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. > > > > I somewhat suspect seriously that the problem is related to this thread: > https://reviews.llvm.org/D124563 > > I didn't dig into all the details (yet). > > =================================== > git show c9a16e8c3d99173c7525e576d78eed571 Drop '* text=auto' from > .gitattributes and normalize > > Git wants to check in 'text' files with LF endings, so this changes them > in the repository but not in the checkout, where they keep CRLF endings. > > Differential Revision: https://reviews.llvm.org/D124563 > -------------------- > I don't know, if this was a good change or not. > If folks wants CRLF in their working tree, there are 3 ways to do so: > - Set core.autoclrf to true > - Set core.eol to CRLF > (This works on Windows and Unix) > > Or, if everybody should have CRLF in the working tree, we could (and should) still > have LF in the repo. > > Just set > > *myfiles.cpp text=auto eol=crlf > > In other words > (I may be wrong due a lack of time to dig deeper into the llvm repo) the problem > seems to come from upstream. > > And we could find out, what upstream really wants and needs, and may be able > to help here. > > Is this maybe something you can do, contact upstream ? No, I could not as I'm not a llvm contributor. Here is another related discussion, hopefully could be useful -- https://reviews.llvm.org/D48494 Actually, I don't quite understand what your suggestions are. Are you telling it's not a git bug but an invalid setup in the llvm-project repo? If 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. Or you agree it's a bug. Then I'd ask to propose your recommendations as a temporary (or permanent) workaround. Could you please clarify?
