There's also an option that makes everyone happy: Let the git installation on a user's machine decide which line ending to use when a repository is checked out:
* text=auto
That way it really doesn't matter and Windows users can still open their files using Notepad if they wish (I'm not judging 😄).
AFAIK line endings are committed to the repository "normalized" as LF, but the checked out version depends on the OS default for line endings.
The setting can be also fine tuned with additional overrides in case there are specific file types that need their line endings preserved (e.g. shell scripts or Windows batch files)
This doesn't work because if you have ESLint set to error then (like to error on Prettier) than Windows developers will get CRLF endings with errors on every line. They'll have to "eslint . --fix" and make a fake commit to fix the problem.
text=auto can't be the solution, since it's the default...
I think your remark misses the point I was originally trying to make, which is to give developers the freedom to use whatever line ending they want to use on their development platform.
Enforcing \n via ESlint rule defies that purpose, so why did you set up your project with that .gitattributes rule?
Also why don't you just disable that line ending ESlint rule since it's safe to assume that the line endings are always correct on the platform where you check out and build your project. There is no point in checking for \n line endings using that .gitattributes setting.
I agree 100% that the ESLint line ending rule is pointless and dumb. But I find that a ton of open source projects enforce it, while few have .gitattributes files.
So instead of convincing a library to change their ESLint settings, the .gitattributes file (* text eol=lf) absolutely fixes the issue for Windows developers without other changes. For everyone else, it's just pointless.
If you are using ESLint to enforce Prettier settings, it makes sense. But it will also cause the error. You could fix it by changing the ESLint rule, because it's pointless, but it's easier to add .gitattributes instead, I think.
To put it another way, you'd never accept a contribution from a Windows contributor using Notepad in the first place, because they can't use Prettier. (OK, they could run Prettier and ESLint manually, but it's just not a realistic development environment.) So since you're already enforcing Prettier to the point of erroring on it, then you might as well force them to download the correct line endings when checking out.
Haha I moved to macOS at the start of the year and I miss notepad. :P
TextEdit can be configured close but it's not the same.
I also never realised how much I used WIN+R as a quick scratchpad when I found myself distracted by another task but still had something live in my clipboard.
Currently using Joplin. It is amazing, and a quick look at Quiver yields a very similar look. I don't know of any implementation that allows "sharing" notebooks like I saw in a screenshot of Quiver, but otherwise, Notebooks with sub-notebook organization, Markdown is possible. Also, there seem to be a lot more methods for accessing Joplin on different platforms, with Windows/MacOS/Linux/Android/iOS/Terminal implementations with DropBox and other file storage services. Highly recommended.
Also, Joplin is FREE. Major bonus.
I admit to still typing notepad into Run/cmd/PS on occasion, but I swear it's only for notes I plan to throw away quickly lol
Literally me, lol!
Windows + R, type notepad, and then dump my thoughts in there from time to time (usually my TODOs for the day). It's good to have such a minimal editor on hand, without all those UI distractions.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Install Notepad2-mod, choose to replace Notepad when you install it, and you'll get all the lightweight joy of old Notepad with just enough extra sprinkles (like lf support and syntax highlighting) to make it practical.
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.
There's also an option that makes everyone happy: Let the git installation on a user's machine decide which line ending to use when a repository is checked out:
That way it really doesn't matter and Windows users can still open their files using Notepad if they wish (I'm not judging 😄).
AFAIK line endings are committed to the repository "normalized" as
LF, but the checked out version depends on the OS default for line endings.The setting can be also fine tuned with additional overrides in case there are specific file types that need their line endings preserved (e.g. shell scripts or Windows batch files)
See also: help.github.com/en/github/using-gi... and git-scm.com/docs/gitattributes
This doesn't work because if you have ESLint set to error then (like to error on Prettier) than Windows developers will get CRLF endings with errors on every line. They'll have to "eslint . --fix" and make a fake commit to fix the problem.
I think your remark misses the point I was originally trying to make, which is to give developers the freedom to use whatever line ending they want to use on their development platform.
Enforcing
\nvia ESlint rule defies that purpose, so why did you set up your project with that.gitattributesrule?Also why don't you just disable that line ending ESlint rule since it's safe to assume that the line endings are always correct on the platform where you check out and build your project. There is no point in checking for
\nline endings using that.gitattributessetting.Hey Thomas! Thanks for your thoughtful reply.
I agree 100% that the ESLint line ending rule is pointless and dumb. But I find that a ton of open source projects enforce it, while few have .gitattributes files.
So instead of convincing a library to change their ESLint settings, the .gitattributes file (* text eol=lf) absolutely fixes the issue for Windows developers without other changes. For everyone else, it's just pointless.
A common ESLint configuration file errors on prettier/prettier, ala Tailwind: github.com/tailwindlabs/tailwindcs...
If you are using ESLint to enforce Prettier settings, it makes sense. But it will also cause the error. You could fix it by changing the ESLint rule, because it's pointless, but it's easier to add .gitattributes instead, I think.
To put it another way, you'd never accept a contribution from a Windows contributor using Notepad in the first place, because they can't use Prettier. (OK, they could run Prettier and ESLint manually, but it's just not a realistic development environment.) So since you're already enforcing Prettier to the point of erroring on it, then you might as well force them to download the correct line endings when checking out.
ESLint even recommends .gitattributes over changing the ESLint setting from its default eslint.org/docs/rules/linebreak-st...
Thanks for this additional information. Please NO, not Notepad!!! 😀
Haha I moved to macOS at the start of the year and I miss notepad. :P
TextEdit can be configured close but it's not the same.
I also never realised how much I used WIN+R as a quick scratchpad when I found myself distracted by another task but still had something live in my clipboard.
Try sublime text!
Check out Quiver for macOS. Create notes within notebooks, and each note can have cells of markdown, code blocks, or sequence diagrams.
happenapps.com/#quiver
For other platforms, check out Joplin. It's not as nice as quiver, but shares some of the same ideas.
I miss that app so much... I switched to Linux from Mac OS a while ago, and that one was one of my most favorite productivity apps.
My crude workaround at the moment is Typora. It's not bad, but not nearly as polished as Quiver.
I will check out Joplin soon. Thanks for the tip!
Currently using Joplin. It is amazing, and a quick look at Quiver yields a very similar look. I don't know of any implementation that allows "sharing" notebooks like I saw in a screenshot of Quiver, but otherwise, Notebooks with sub-notebook organization, Markdown is possible. Also, there seem to be a lot more methods for accessing Joplin on different platforms, with Windows/MacOS/Linux/Android/iOS/Terminal implementations with DropBox and other file storage services. Highly recommended.
Also, Joplin is FREE. Major bonus.
Literally me, lol!
Windows + R, typenotepad, and then dump my thoughts in there from time to time (usually my TODOs for the day). It's good to have such a minimal editor on hand, without all those UI distractions.I'm a heavy Windows desktop user. But live primarily in wsl terminal nowadays.
Btw, that Regex would match Unux😝
Ah, the glory days of Unux and Linix.
Install Notepad2-mod, choose to replace Notepad when you install it, and you'll get all the lightweight joy of old Notepad with just enough extra sprinkles (like lf support and syntax highlighting) to make it practical.
xhmikosr.github.io/notepad2-mod/
I'm about 2 years late, but Notepad has actually been able to read LF line endings since 2018: devblogs.microsoft.com/commandline... :)
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.