I'm a coder who has worn a lot of hats, from individual contributor to lead engineer to "CTO" (yes, in quotes, make of that what you will!). I've a lot to learn and hopefully some to share as well.
As a (mainly) Windows user I always disable autocrlf and standardize on LF because:
If I'm building Docker images (and I often am), I don't want to be copying CR LF files into the Docker images. Some Linux utilities will choke on them.
If my program reads, say, XML files, I don't want the (multiline) strings going through my code to differ depending on my OS, this has bit me before too.
If I calculate a hash on a file I want it to be the same on any OS.
While I have had problems with CR LF files on Linux, I have never had problems with LF files on Windows (I don't use Notepad).
I'm a software developer interested in front- and back-end and the supporting architectures (basically everything 😎). Currently focused on front-end development with Angular and nx dev tools.
@mistval Thanks for your comment, it got me thinking 😃.
For 1., isn't it wise to convert the line-endings to fit the target OS anyway? In your situation, if you want a Windows image in the future and copy over any files with LF endings, you will have the same problem.
For 2., this would also be solved if you take the solution from up above, convert the line-endings before running your code as a Docker container. But it depends on your use case as well: What are the files used for?; Who will use them in the future? etc.
For 3., if you use git hash-object to calculate the hash it will take into account the core.autoclrf or text=auto settings so the hash should be the same, even on a different OS.
You could also have issues on Windows by defaulting to LF for non-binary files like .bat.
I'm a coder who has worn a lot of hats, from individual contributor to lead engineer to "CTO" (yes, in quotes, make of that what you will!). I've a lot to learn and hopefully some to share as well.
Hi Joep, you have some good points. I suppose I just am rarely in situations where LF breaks things. I rarely run .bat files and I never build Windows images.
Ultimately it's ideal if repos have .gitattributes, if not, I've had a lot more luck with configuring git to default to LF than using autocrlf.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a (mainly) Windows user I always disable autocrlf and standardize on LF because:
If I'm building Docker images (and I often am), I don't want to be copying CR LF files into the Docker images. Some Linux utilities will choke on them.
If my program reads, say, XML files, I don't want the (multiline) strings going through my code to differ depending on my OS, this has bit me before too.
If I calculate a hash on a file I want it to be the same on any OS.
While I have had problems with CR LF files on Linux, I have never had problems with LF files on Windows (I don't use Notepad).
@mistval Thanks for your comment, it got me thinking 😃.
For 1., isn't it wise to convert the line-endings to fit the target OS anyway? In your situation, if you want a Windows image in the future and copy over any files with LF endings, you will have the same problem.
For 2., this would also be solved if you take the solution from up above, convert the line-endings before running your code as a Docker container. But it depends on your use case as well: What are the files used for?; Who will use them in the future? etc.
For 3., if you use
git hash-objectto calculate the hash it will take into account thecore.autoclrfortext=autosettings so the hash should be the same, even on a different OS.You could also have issues on Windows by defaulting to LF for non-binary files like
.bat.Hi Joep, you have some good points. I suppose I just am rarely in situations where LF breaks things. I rarely run
.batfiles and I never build Windows images.Ultimately it's ideal if repos have
.gitattributes, if not, I've had a lot more luck with configuring git to default to LF than using autocrlf.