How to repair CRLF in GIT repository to avoid merg

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 autocrlf (OS Win):

case if autocrlf=true

WorkingTree ->  commit  -> GITRepository
CRLF         CRLF to LF      LF
LF           no conv.        LF
WorkingTree <- checkout <- GITRepository
CRLF         LF to CRLF      LF

case if autocrlf=false

WorkingTree ->  commit  -> GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF
WorkingTree <- checkout <- GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF

Now I would like to use GIT with autocrlf=false, so I decided to checkout each branch, repair eols of source files with utility EOL converter and commit back with CRLF. I did it, but after time, there are still some files, which probably were not checked out after I changed setting of autocrlf to false (or these files came to merge from older not fixed commits? During conversion I used mask *.filetype to automate processing all LF to CRLF so there's no other explanation for such situation for me). I also tried to touch the files, to re-commit them all (as I saw somewhere here in stackoverflow) but date change is not relevant for GIT AFAIK. I have also read How to undo the damage of autocrlf, but not sure it's my case, and also don't understand the wizard's tricks.

How can I get away from this mess, please?

回答1:

Use the git merge option "ignore-space-change" or "ignore-all-space" for the "recursive" strategy. This option is in 1.7.4.1, at least.

回答2:

Easy answer: Unless you ARE doing x-platform dev with non-Windows, set this to false. There is no need for your source control to bastardize your files for you. After fixing any remaining issues you should be flying. Make sure the others working with you also set this to false.