Re: git reset --hard can leave modified files

["Torsten Bögershausen" <tboegi@web.de>]

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.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.
>

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 ?