Explicitly normalize on Unix line-endings with FreeBSD sources

[ngie]

Summary

Many tools in FreeBSD don't play well with Windows line-endings, e.g.,
make. Change the value from the client default, which is CR on Unix and
CRLF on Windows by default to CR (Unix) for all non-third party sources,
e.g., contrib/, sys/contrib/, etc. This avoids a large amount of
grief when building or editing sources in the FreeBSD tree.

Any fine-grained line-endings attributes should be added to appropriate
.gitattributes files under their respective subdirectories. Two of
those files were added for the bintrans and diff3 tests as they leverage
CRLF line endings in the tests.

Reported by: Linnea Damer <[e-mail]>
MFC after: 2 weeks
Relnotes: yes

Test Plan

The following chained command showed no changes in my source tree:

git rm --cached -r .
git reset --hard
git status -uno
git add --renormalize .
git status -uno

[markj]

This avoids a large amount of grief when building or editing sources in the FreeBSD tree.

Could you please describe the grief? It's not obvious to me what problem this is solving.

[ngie]

@markj: this change avoids a large amount of grief when building or editing sources on hosts that are incorrectly configured, and/or on Windows hosts. I'm not sure what exactly Linnea did to trigger this, but I assume it had to do with hosting or editing the sources on a Windows box.

[junchoon_dec.sakura.ne.jp]

Summary looks need fixing.

Change the value from the client default, which is CR on Unix and

CRLF on Windows by default to CR (Unix) for all non-third party sources,

This part should be:
Change the value from the client default, which is LF on Unix and
CRLF on Windows by default to LF (Unix) for all non-third party sources,

IIRC, MacOS (at least prior to MacOSX) used CR (\r), though, Unix and variants (including BSDs) historically use LF (\n).

[jrtc27]

.gitattributes is a footgun and can give confusing behaviour. tools/build/checkstyle9.pl should enforce this for GitHub PRs already, and clang-format can (will?) normalise this too. There are significant downsides for this with little benefit that I can see.

[des]

The summary is incorrect. Early operating systems including DEC's TOPS-10 and VMS used CR LF because that was what teletypes expected. CP/M was heavily inspired by TOPS-10 and continued to use CR LF despite rarely if ever being used with teletypes. DOS inherited CR LF from CP/M, and Windows inherited it from DOS; Windows NT and OS/2 borrowed heavily from VMS which also used CR LF, in addition to needing to remain compatible with DOS and pre-NT Windows. Apple historically used CR but switched to LF with Mac OS X (later renamed to macOS). Unix and its descendants (such as Plan 9) have always used LF despite originally being written for teletypes, relying instead on the device driver to inject a CR if needed.

[ngie]

In D54062#1243684, @jrtc27 wrote:

.gitattributes is a footgun and can give confusing behaviour. tools/build/checkstyle9.pl should enforce this for GitHub PRs already, and clang-format can (will?) normalise this too. There are significant downsides for this with little benefit that I can see.

The problem was that someone shot themselves in the foot at $work because they had edited a file on a Windows machine, pushed it into the $work repo, and it was failing to build when processing the Makefile in non-sensical ways.

It ate up about 2 hours of my time working with another engineer (it involved protracted Slack back and forth and I finally figured out what was wrong as part of a Zoom meeting). Once I opened up the file in vim it was immediately obvious what the problem was since vim's syntax highlighter highlighted the carriage returns, whereas it was not at all obvious based on the other information I had received from the other engineer.