1

PSR-12 for PHP and Airbnb's ESLint config for React requires LF line endings over CRLF. I see in the ESLint docs that they recommend adding a .gitattributes file with content similar to this:

*.js text eol=lf

I checked the Git documentation and it mentions that using eol can make paths be considered dirty. What is meant by this? I also notice there's mentions of core.safecrlf later in the docs, so can these types of conversions cause irreversible problems?

Will I also need to set core.autocrlf to false so that .gitattributes takes effect?

SomeRandomDev
  • 129
  • 11
  • 1
    Don't use CRLF line endings and none of this is ever going to matter. Just `git clone ... --config core.autocrlf=false` and configure your editor(s) to default to git settings (if available) or LF. – IInspectable Jul 31 '21 at 14:47
  • @IInspectable We do that currently. Just looking for a way to standardise it so everyone on the team is using LF line endings at the project-level. – SomeRandomDev Jul 31 '21 at 14:51

1 Answers1

3

When you set a file in text mode in Git, that tells Git that you want it to perform end-of-line conversion. That means that Git will always write the file into its internal storage with LF endings, and then check out the endings that are specified, whether that's due to .gitattributes or various configuration options.

If, however, the repository already contains files with CRLF line endings checked in, then setting the eol option will cause the file to be checked into the repository with LF endings, as mentioned above. This will make Git think the file is modified, which it is. That's what's meant by making "the paths to be considered dirty."

The easiest way to solve this problem is to add the entries to .gitattributes, add the .gitattributes file, and then run git add --renormalize . and then commit. That way, any files which had CRLF endings will be converted to LF endings in the repository.

You don't also need to set core.autocrlf in addition. That behavior is overridden by the .gitattributes file.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • That clears it up I think. Considering the default option in Git Setup is to "Checkout Windows-style, commit Unix-style line endings", I presume that most of the files in our repos are already in LF format. – SomeRandomDev Jul 31 '21 at 15:10
  • In this case would running `git pull` revert the files back to CRLF? I may be misunderstanding this post on SO: https://stackoverflow.com/a/62367282/7487871. – SomeRandomDev Jul 31 '21 at 15:12
  • It should not. In that case, someone checked files with CRLF into the repository and didn't renormalize, and as a result, the CRLF files were not converted and were checked out that way. If you renormalize, the problem goes away. – bk2204 Jul 31 '21 at 15:19
  • Sorry, if these are silly questions. Would the files than be converted to LF when pushed to the repository in a commit? Also, is there anything else I should consider (e.g., risks or anything)? – SomeRandomDev Jul 31 '21 at 19:21
  • 1
    When files are added into the repository with `git add` (including updates to existing files or with the `--renormalize` option), they'll be converted into LF. There are no risks unless you accidentally mark binary files (e.g., images) as text files. – bk2204 Jul 31 '21 at 19:41
  • Okay, thanks for your help @bk2204. I can't think of anything left to answer so I'll mark this as the answer. – SomeRandomDev Jul 31 '21 at 19:52
  • @JamesFromIT Regarding risks: If binary files are mistaken as text you can garble the file. See https://dba.stackexchange.com/a/264751/236391 – Rusi Aug 03 '21 at 15:40
  • Hi @Rusi, thanks for the response. I'll only be applying this rule to `*.js` and `*.php` files so that should be fine. – SomeRandomDev Aug 04 '21 at 14:35
  • @JamesFromIT : You may find [my guide](https://stackoverflow.com/a/59644154/3700414) useful – Rusi Aug 04 '21 at 14:44
  • @Rusi - If I somehow mess it up, I pressume I can just revert changes? – SomeRandomDev Aug 04 '21 at 14:53
  • @JamesFromIT the dba link above shows that binary files treated as text (by misconfigured gitattributes) are messed from their commit itself. So revert would be useless. Otoh text files treated as binary will show spurious changes bad diffs etc. In short, you are obliged to properly classify all your files as text/binary upfront. Don't skimp on this. And don't use "* text= auto" because that asks git to guess – Rusi Aug 04 '21 at 15:01
  • I think you mean `git add . --renormalize`, not `git add --renormalize`. – Gabriel Staples Jul 26 '23 at 20:18
  • No, I didn't. Options like `--renormalize` go before non-option arguments like `.`. Note that I wrote `git add --renormalize .` and not `git add --renormalize` (that is, there is a trailing `.` argument). – bk2204 Jul 27 '23 at 21:07