-1

I've read a lot about git's line ending normalization and already learned that .gitattributes seems to be the way to go. But I read many pros and cons for line ending normalization in general, especially with windows. So for me the question is...

Is line ending normalization good or bad practices?

I also look into bigger repositories and I never saw any kind of line ending normalization f.e. Qt.

So for me (or other people) it is really interessting what you, the reader of this post, use? And what's your though about such topic.

Michael Aigner
  • 4,820
  • 4
  • 21
  • 33
  • Your question is likely to be closed as "primarily opinion based" which it, frankly, probably is. So a quick comment (not an answer) with my own opinion: yes, absolutely use `.gitattributes` (do _not_ rely on `core.autocrlf`, since it requires everybody to have the same settings, which will inevitably not be the same due to human nature). It's probably still a best practice to do the conversion, even if you're an entirely Windows shop. Back in ye olde days, some Git commands failed spectacularly on files with CRLF line endings... – Edward Thomson Dec 17 '18 at 12:58
  • That's mostly (entirely?) all fixed, but unless you have a compelling reason to avoid normalization (huge repository and the speed of the filters is hurting you, etc) then it's probably still a best practice to do the conversion. You'll be much happier if you ever _do_ add a non-Windows developer to the team. – Edward Thomson Dec 17 '18 at 13:00

1 Answers1

0

If your Git project will ever be used by people on multiple platforms for any reason, you will want to use Git's line ending normalization. Users on non-Windows systems won't want to have CRLF endings, since carriage returns tend to show up in Git diff output as trailing whitespace on those platforms. However, Windows tools (including editors and compilers) often need CRLF endings to work. Without using line ending normalization, users are likely to make mistakes and accidentally commit the wrong line ending, causing diff noise.

Having said that, you need not use .gitattributes to handle line endings. It's often sufficient on Windows to use the core.autocrlf setting, since Git can detect most binary files and not change the endings on them, while changing the line endings on any text files. If this is suitable for your repository, then there's no need for a .gitattributes file at all.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • The problem with `core.autocrlf` is not about detection of binaries (`.gitattributes` does identical detection), it's about the locality of the setting. If you try to use `core.autocrlf` then you need to coordinate the configuration across everybody's installation. Somebody will inevitably set `core.autocrlf` to the wrong thing and some people will be checking in `\r\n`, others just `\n`, and working directories will appear dirty. `.gitattributes` forces the same settings for everyone since it's checked in. `.gitattributes` is _always_ preferred. – Edward Thomson Dec 17 '18 at 12:50
  • I honestly think that if you're working on Windows, `core.autocrlf` is a basic requirement for Git to work as it's intended to. There's no good reason (other than historical repositories) not to set it. It may be that `.gitattributes` is more foolproof, but with standardized development environments or in a small group of developers, `core.autocrlf` is indeed sufficient. – bk2204 Dec 19 '18 at 00:41
  • There’s no “more foolproof”, there is “foolproof” and not. `core.autocrlf` is not. It’s outdated and should not be relied upon. Telling people that it’s “good enough” persists broken repositories with a mangled mix of line endings. – Edward Thomson Dec 19 '18 at 15:50