Normalized line endings from CRLF to LF

[Vlad-Zumer]

This has led to an issue where after cloning, the repo would show unsaved changes even from a newly created fork.

[alexanderfast]

Great that they are normalized. But why LF instead of CRLF? Is it Unity that does this? Can't it be configured? I would assume that the Windows style would make more sense.

[Vlad-Zumer]

@Mizipzor Well yes it can be configured (link here) but Git is very picky about that because it was originally made for Unix systems, ie. Linux, from what i understand, and also it let's people from other systems like Mac and Linux contribute to the project.

How to configure:

• open git terminal
• write:
  • git config --global core.autocrlf true - for Windows (this will change all CRLF to LF only on the export files and LF to CRLF on the files that you import)
  • git config --global core.autocrlf input - for Mac/Unix (this will change any CRLF from the import to LF but not the other way around)

[alexanderfast]

I wouldnt want to do it globally because I actually think it should be LF. I just meant for this project specifically. And maybe I have misunderstood Git but isn't it meant to have git convert it all when something is checked out or committed? Windows user does checkout, everything is coerced to CRLF, windows user submits CRLF but its converted to LF.

[alexanderfast]

I just checked, these files and all other files have CRLF for me.

[quill18]

This conflicts with our "native EOL" CONTRIBUTION.md standards and the .gitattributes auto-eol configuration we implemented in #41. Your local git should pull files into your native eol for whichever system your on -- unless we've made a mistake somewhere.

Try doing a fresh clone and check to see of the eol are right for your system.

[alexanderfast]

@quill18 I actually cant find a segment addressing the eol in the contributions file. Is it somewhere else? Or did I just miss it?

[brlodi]

@quill18 @2DemiGods I am still seeing this issue when making a fresh clone on OS X. The following files are downloading with CRLF (Windows) line endings, causing them to appear immediately as "changed":

• Assets/Resources/Fonts/Cubellan_v_0_7/Cubellan_License_SIL_OFL.txt
• Assets/Resources/Fonts/Cubellan_v_0_7/Read_Me.txt
• Assets/Resources/Fonts/osp.foundry.alfphabet/OFL-FAQ.txt
• Assets/Resources/Fonts/tgl/OFL-FAQ.txt
• Assets/Resources/Fonts/tgl/Open Font License.txt

Based on some Google-fu I think this behavior is caused by the files not having been recommitted after the settings change in #41, so they aren't marked for "auto" line endings in the repo. They download without the intelligent conversion, but when checking them against the previous commits git does convert the line endings first i.e. the local file has "auto" EOL while the repository file has explicit CRLF line endings. Windows users probably don't see an issue, since their line endings will match anyway, but users on *nix systems will show changes for freshly downloaded files.

GitHub has a help article about it here: https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings. To preserve attribution this is probably something @quill18 should handle himself.
EDIT I should I say that I'm not suggesting the nuclear option from the GitHub article, just that the individual files with issues need to be re-normalized

[henninglive]

@brlodi I have the same problem. I use the Msys2 Git client on Windows. Maybe @quill18 can try this, from Gitattributes Documentation:

# From a clean working directory:

$ rm .git/index  # Remove the index to force Git to re-scan the working directory
$ git reset      # Git should automatically normalize all text files on checkout.
$ git status     # Show files that will be normalized
$ git add -u
$ git commit -m "Introduce end-of-line normalization"

[QuiZr]

Should be fixed in #187. As @henninglive pointed out:

When text=auto normalization is enabled in an existing repository, any text files containing CRLFs should be normalized. If they are not they will be normalized the next time someone tries to change them, causing unfortunate misattribution.

[alexanderfast]

So there was a problem with the repo itself! I learned something new today. :)

[brlodi]

@QuiZr is correct that #187 will fix this problem. We just need someone to commit the normalized .txt files, and it would be nice if was a PR for the specific issue, rather than an incidental change from a different one, so the reasoning is documented (I think #187 qualifies).