0

git allows CRLF, CR and LF as line feeds/EOL. What is the recommended way to deal with them:

  • allow all contributors to use whatever EOL and ignore it in git's diff (e.g. with git config core.whitespace cr-at-eol as suggested in git-diff to ignore ^M) (which disadvantages?)
  • define one line feed to be used for the project, notify all contributors about it in CONTRIBUTING or HACKING and enforce it by refusing patches which don't comply (more work)
  • let everything be converted by git by setting git config --global core.autocrlf true
Community
  • 1
  • 1
Kalle Richter
  • 8,008
  • 26
  • 77
  • 177
  • possible duplicate of [What's the best CRLF (Carriage Return Line Feed) handling strategy with git?](http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git) – Edward Thomson Mar 05 '15 at 18:04
  • @EdwardThomson my question is not about handling CRLF, but all sorts of line feeds (the set of solutions overlaps, though) – Kalle Richter Mar 05 '15 at 20:13

2 Answers2

0

Letting git handle it is the preferred method most of the time.

This is because you don't know what platforms you will have people working on your project. Each program also handles line endings differently, Atom Editor uses LF always, it doesn't care about the platform it is being ran on.

Due to each OS and program handling the line endings differently, let git handle that stress, and keep on coding!

Ryen Nelsen
  • 367
  • 1
  • 9
  • So just to make sure, you mean `git config --global core.autocrlf true` and there's no other way to let `git` "handle" it? – Kalle Richter Mar 05 '15 at 15:58
  • @KarlRichter It ultimately depends on the project. If your project depends on crlf line endings, then forcing it would be ideal (in .gitattributes). Otherwise, just leaving the value at the default instead of globally setting it would be better. Check out this [article](http://lostechies.com/jimmybogard/2012/03/08/git-core-autocrlf-settings-poll-results/). – Ryen Nelsen Mar 05 '15 at 16:02
0

No. Don't trust your users to get this right. They won't, and it's a subtle problem until you get people complaining about weird merge conflicts, strange messages at checkout and status showing files modified when they "haven't been".

Set up a .gitattributes for your repository:

* text=auto
Edward Thomson
  • 74,857
  • 14
  • 158
  • 187