* git reset --hard can leave modified files
@ 2022-04-29 15:50 Mirochnik, Oleg V
2022-04-30 4:49 ` Torsten Bögershausen
0 siblings, 1 reply; 6+ messages in thread
From: Mirochnik, Oleg V @ 2022-04-29 15:50 UTC (permalink / raw)
To: git@vger.kernel.org
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\r
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git reset --hard can leave modified files
2022-04-29 15:50 git reset --hard can leave modified files Mirochnik, Oleg V
@ 2022-04-30 4:49 ` Torsten Bögershausen
2022-05-02 18:37 ` Mirochnik, Oleg V
0 siblings, 1 reply; 6+ messages in thread
From: Torsten Bögershausen @ 2022-04-30 4:49 UTC (permalink / raw)
To: Mirochnik, Oleg V; +Cc: git@vger.kernel.org
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.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"
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: git reset --hard can leave modified files
2022-04-30 4:49 ` Torsten Bögershausen
@ 2022-05-02 18:37 ` Mirochnik, Oleg V
2022-05-02 19:26 ` Torsten Bögershausen
0 siblings, 1 reply; 6+ messages in thread
From: Mirochnik, Oleg V @ 2022-05-02 18:37 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git@vger.kernel.org
> -----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.
\r
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git reset --hard can leave modified files
2022-05-02 18:37 ` Mirochnik, Oleg V
@ 2022-05-02 19:26 ` Torsten Bögershausen
2022-05-02 22:07 ` Mirochnik, Oleg V
0 siblings, 1 reply; 6+ messages in thread
From: Torsten Bögershausen @ 2022-05-02 19:26 UTC (permalink / raw)
To: Mirochnik, Oleg V; +Cc: git@vger.kernel.org
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 ?
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: git reset --hard can leave modified files
2022-05-02 19:26 ` Torsten Bögershausen
@ 2022-05-02 22:07 ` Mirochnik, Oleg V
2022-05-04 15:42 ` Torsten Bögershausen
0 siblings, 1 reply; 6+ messages in thread
From: Mirochnik, Oleg V @ 2022-05-02 22:07 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git@vger.kernel.org
> -----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 ?
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?
\r
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git reset --hard can leave modified files
2022-05-02 22:07 ` Mirochnik, Oleg V
@ 2022-05-04 15:42 ` Torsten Bögershausen
0 siblings, 0 replies; 6+ messages in thread
From: Torsten Bögershausen @ 2022-05-04 15:42 UTC (permalink / raw)
To: Mirochnik, Oleg V; +Cc: git@vger.kernel.org
On Mon, May 02, 2022 at 10:07:11PM +0000, Mirochnik, Oleg V wrote:
[]
> >
> > 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.
You can become one ;-)
> 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?
Yes
> 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?
Now, the documentation, which I think you ask for, is here:
https://git-scm.com/docs/gitattributes
If I look at the repo, commit 4ff40855fcc0c1320f31350bc9e93d4d6ce6891f
(HEAD -> git-bug-reproducer, origin/git-bug-reproducer)
and run the official eol-diagnostic tool:
$ git ls-files --eol >eol-prob.txt
and then
$ grep "^i/crlf.*attr/text" eol-prob.txt
I get 9 files listed, so I pick the first one for a discussion:
i/crlf w/crlf attr/text eol=crlf clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
What we have in the repo is a "conflict".
The attributes says it is a text file, and the index file (what had been commited)
has CRLF.
Git can not resolve the conflict.
(setting text=auto could work. Or normalize. Or both. Normalization is recomended anyway)
So, the solution would be to renormalize all files:
$ git add --renormalize .
(The . is important)
After that you will see those 9 files modified, and they need to be commited.
In general, for a cross-platform project, it could be useful to set up a
.gitattributes file in the top directory, with one line:
* text=auto
That file can then be tweaked for BAT or sh files as needed.
That should all be in the documentation - if not, please ask and/or send us
patches.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-04 15:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-29 15:50 git reset --hard can leave modified files Mirochnik, Oleg V
2022-04-30 4:49 ` Torsten Bögershausen
2022-05-02 18:37 ` Mirochnik, Oleg V
2022-05-02 19:26 ` Torsten Bögershausen
2022-05-02 22:07 ` Mirochnik, Oleg V
2022-05-04 15:42 ` Torsten Bögershausen
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).