3

I've inherited a repo that's been developed on Windows and has always been hosted on Windows. Historically, autocrlf has been disabled, so our main repo will have crlf line endings.

However, we're moving to more of a cross-platform situation, so we want to enable autocrlf.

I've tried running git add --renormalise . as per these answers but when I try and commit it, there are no changes, presumably because they're already CRLF and I'm on Windows, so I can't push it to have it renormalised on the remote.

How would I go about doing this? Do I need to check it out on a Unix machine then do a push?

ScottishTapWater
  • 3,656
  • 4
  • 38
  • 81
  • Do you have an `.gitattributes` (https://git-scm.com/docs/gitattributes) file? I'm not 100% sure it's required for that but maybe it's some clue. – Piotr Siupa Jan 28 '23 at 17:18
  • We don't yet, we were planning on adding it after we'd renormalised on a branch and checked everything was okay – ScottishTapWater Jan 29 '23 at 13:40
  • I'm not expert on that but what I would do is to add `.gitattributes` in which all text files are explicitly stated as such so git knows which files to renormalise. Then commit the file and then `git add --renormalise .`. I don't know if all the steps are necessary but I know that the full procedure always worked for me. – Piotr Siupa Jan 29 '23 at 15:24
  • @PiotrSiupa - I will try it and get back to you tomorrow :) thank you my friend – ScottishTapWater Jan 29 '23 at 16:24

1 Answers1

3

The git add --renormalize . I mention with Git 2.16+ (Q1 2018) works in collaboration with git config and .gitattributes

Add and commit a .gitattributes with:

*.txt text eol=lf

Then add (with the renormalize option), and commit if needed.

Cloning that repository (with the .gitattributes directives in it) will result in .txt file keeping one consistent EOL (here LF).
Since most Windows IDE/editor know how to preserve LF, that is more convenient for cross-platform development.
And that allows you to keep git config --global core.autocrl false, which I have always recommended.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Having LF line endings will break some things on Windows though. Sure, IDEs can cope, but not everything can. – ScottishTapWater Jan 30 '23 at 09:22
  • 1
    @ScottishTapWater You do not have to specify LF for *all* txt file. The idea with a .gitattributes file is to version the directives you need for exactly the files you want managed. As opposed to `core.autocrlf`, which impact *everything*. – VonC Jan 30 '23 at 09:31
  • Sure, but what's wrong with just committing LF and checking out CRLF on Windows but LF and LF on Linux? That seems like the optimal solution here. I don't really want to rely on everyone always opening these files in an IDE... The second someone opens something in notepad it'll change the line endings – ScottishTapWater Jan 30 '23 at 09:45
  • 2
    @ScottishTapWater I would recommend to *not* depend on automagic transformation: pick one EOL style for specific files or group of files and make sure the development environment does not impact it. Even the good old Notepad understand LF now, as I [mentioned here](https://stackoverflow.com/a/2825829/6309), for [Windows 10 2018.09+](https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/). – VonC Jan 30 '23 at 10:03
  • I would hope that a well tested, fairly old feature in git works after it's existed for this long... Good news about Notepad though... If Powershell can handle it too... you might be right – ScottishTapWater Jan 30 '23 at 10:07