How do we handle the newline issue while "everyone can contribute"?

I want everyone in the world to use Git to collaborate, what is the best way to handle this while including "everyone".

Here is the problem

On this commit, we ended up with some "newline noise" at the end of the file and didn't know how to best handle it in the context of the www-gitlab-com project.

https://gitlab.com/gitlab-com/www-gitlab-com/commit/97c865672f909a9894814c667b0b17ff844b2026

The explanations on the internet are great, but they expect everyone dealing with this issue to be as interested in the history of Unix as I am.

https://robots.thoughtbot.com/no-newline-at-end-of-file

Our own guides for this, seem like the type of thing that most people coming from a non-technical background, would just gloss over.

https://about.gitlab.com/handbook/#prevent-newlines-from-causing-all-following-lines-in-a-file-to-be-tagged-as-changed

Also see #2 (closed) here https://about.gitlab.com/handbook/#writing-style-guidelines

I see 3 options, please pick one or suggest more.

1. Ignore the issue and keep working around it.
2. Use git blame when we see it and reach out to the person in a friendly manner and suggest they change settings in their text editor.
3. Add something to our style guide saying that we put an actual empty line at the end of each file.

Added Team documentation handbook labels

@dewetblomerus this is a perpetual problem, partially because making edits through the web UI allows for / does not strip trailing spaces.

However, it's not a big deal because:

• it's not altering content or look of a page
• in the merge request diff view, you can click on "Hide whitespace changes", which makes it go away for MR revision
• any time anyone comes through with an MR generated locally and with the proper settings, all trailing spaces are stripped, and the page is "clean" again for a while.

I vote to "ignore", but if there is a more permanent solution (that does not rely on everyone having the right settings, the writing guidelines memorized, etc.), happy to hear about it :-)

Status changed to closed

Thanks @ernstvn, I am happy to ignore it and move on. After reading your points I think it makes the most sense for this context.