Re: git reset --hard can leave modified files

From: Torsten Bögershausen <tboegi@web.de>
Date: Apr 30, 2022, 04:49 UTC
Message-ID: <20220430044940.6botq23lxmpqxbel@tb-raspi4>
In-Reply-To: <CY5PR11MB6089858FD6FCC971D6F216DDC6FC9@CY5PR11MB6089.namprd11.prod.outlook.com>

On Fri, Apr 29, 2022 at 03:50:59PM +0000, Mirochnik, Oleg V wrote:

Show 52 quoted lines

> 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.expected
>
> 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 ? What does git config core.autocrlf give you ?

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"