3

So, I've recently added a .gitattributes file to one of our repositories to try to force consistent line endings:

  # All Perl Sources should use Unix style line endings
  *.pl text eol=lf
  *.pm text eol=lf

But both myself and a lot of other developers are encountering a lot of "phantom changes" where git seems to detect the file as "changed" even though there's no change. Every line shows up as added, then deleted.

I suspect it's getting confused about line endings (and thus detecting each line as changed), but what's weird here is:

  • I can't reset the file (the reset is completed, but the file remains as an unstaged change)
  • Changing the line endings in the affected text file does not affect whether it shows up as a changed file.

Has anyone encountered this before, and is there a way to avoid or resolve this issue?

Adam Luchjenbroers
  • 4,544
  • 2
  • 25
  • 34
  • 1
    If the *checked-in* version of the file has CRLF endings, you must do one "fix the files" pass once, which will change the checked-in version to be LF-only. After that, all will be OK. – torek Oct 04 '18 at 02:39
  • Is there a good way to check what the checked in file has? - in many of these cases the files in question *should* already have LF endings. – Adam Luchjenbroers Oct 04 '18 at 03:53
  • From my experience when a diff shows every line is changed but they appear to be the same, then the change is with the line endings or spaces/tabs. – Code-Apprentice Oct 04 '18 at 04:39
  • 1
    The easiest way to see for sure what's in the raw version of a file is to read it out with no end-of-line processing. To do *that*, you can: check it out in a repository with no `core.eol` settings and no `.gitattributes` or similar settings or with `.gitattributes` modified to read `* binary`, so that Git does not touch it; use `git cat-file -p ` to extract the raw blob hash data; or use `git archive` in a similar fashion to the `git checkout` method. But see VonC's answer using `--renormalize`, which is usually the way to go if you need to correct them anyway. – torek Oct 04 '18 at 04:59

1 Answers1

2

With Git 2.16 or more, do at least once:

git add --renormalize .
git commit -m "normalize eol files"
git push

Then try and clone your repo elsewhere, and check that git status behaves as expected.

Make sure you don't have core.autocrlf set to true.

git config core.autocrlf

And you can test for your files eol style.

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283