RE: git reset --hard can leave modified files

> -----Original Message-----
> From: Torsten Bögershausen <tboegi@web.de>
> Sent: Monday, May 2, 2022 12:27 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 Mon, May 02, 2022 at 06:37:26PM +0000, Mirochnik, Oleg V wrote:
> > > -----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.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 ?