core.autocrlf

I have Windows machine with VS project and I use both Visual Studio and tools from Cygwin environment including Git. Sometimes I get different line endings in files after editing. I want simple solution to check files' line ending consistency before they go to the repo. Git's core.safecrlf is the right thing I suppose. Now I have a strange behavior: Files A and B with following parameters: $file A A: HTML document, UTF-8 Unicode text, with CRLF line terminators $file B B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators File A is already in repo, file B is new one. Note

I am checking out a third party project "libjpeg" from https://github.com/winlibs/libjpeg on Linux (it is just one example, actually I have the same problem with many other projects as well). I have the following Git line endings configuration. I have only global settings configured (set to checkout with LF line endings): $ git config --system -l | grep core core.eol=lf core.autocrlf=false $ git config --global -l | grep core core.eol=lf core.autocrlf=false There are no local (repo) settings regarding line endings. I read this article about the Git line endings configuration: https:/

I created my repo with autocrlf=true and then made some checkouts and commits with autocrlf=false . Then switched back to autocrlf=true (OS Win). Everything seemed to be OK, until I started some merges between branches. Many merge conflicts arose, where whole file was marked as changed due to changed eols (I suppose it were those files, which were checked out and commited with autocrlf=false ). There is some history, which is worth for me, so I prefer to make some conversion or fixing commits with converted eols rather to creating new repo and starting new life. This is how I understand

I was searching for the proper setting to be used as per certain use cases but could not find any source describing the same. Therefore, I am asking this question to serve as a solution to anyone looking for the correct setting for git's autocrlf option. Use Case 1: I am on Mac, the other developers are all on Windows. They are managing the source code before I joined in. Use Case 2: I am on Windows, the other developers are all on Mac. They are managing the source code before I joined in. Use Case 3: I am on Linux, the other developers are all on Windows. They are managing the source code

Here is my system dialogue: unrollme-dev-dan:views Dan$ git reset --hard HEAD HEAD is now at 3f225e9 Fix scan titles unrollme-dev-dan:views Dan$ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: app/signup/finish.html # modified: app/signup/scan.html # I have autocrlf set to false: unrollme-dev-dan:unroll-website Dan$ git config core.autocrlf unrollme-dev-dan:unroll-website Dan$ unrollme-dev-dan:unroll-website Dan$ git config -

As one can glean from other posts , Git's end-of-line normalization has its pros and cons. I have one particular Windows-only project where I think the best thing to do is to is to disable end-of-line normalization altogether. That is, I want to leave all newlines (most of which are CRLF ) intact, rather than have git normalize them to LF -only behind the scenes, and I want that change to affect all clones of the repository on all machines. The question is the most effective way to do it. Most discussions of Git end-of-line normalization are in terms of core.autocrlf , and I could accomplish

I understand that Windows uses CRLF and that it's good practice to let Git change line endings to LF before committing and back to CRLF when checking out. For that reason, I have core.autocrlf set to true. However, contrary to what other threads say (e.g., this ), I am still getting this warning: warning: LF will be replaced by CRLF in [FILE_NAME]. The file will have its original line endings in your working directory. Firstly, I thought setting core.autocrlf to true was supposed to stop these warnings. Secondly, isn't Git supposed to convert LF to CRLF when committing, not the other way