How to repair CRLF in GIT repository to avoid merge conflicts

Question

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?

Cecilececiley

have you tried autocrlf=input? if your repo was not made publicly available you can use that and filter-branch --index-filter to clean up line endings in your history – Heterogony

@knittl: If I understand, this will rewrite all commits in history with LF. Am I right? Then I will probably have to turn autocrlf=true to get CRLF after checkout (OS Win). Is there an option to convert repo directly to CRLF and leave autocrlf=false after that? – Cecilececiley

once the repository is converted to CRLF you should be able have autocrlf=false thus no line endings are converted and stay the way they are in the file – Heterogony

@knittl: So setting autocrlf=input causes conversion during commit, no conversion during checkout. What exactly happens on Windows machine? Repository will be all CRLF, or all LF? I cannot find this in manual. Thanks. – Cecilececiley

from the git config manpage: »This variable can be set to input, in which case no output conversion is performed.« – Heterogony

@knittl: I understand, but what input conversion will be performed? Ok, I'll try on some test repo, thanks. – Cecilececiley

input conversion should be CRLF→LF – Heterogony

@knittl: Hi again, I tried to use this command, but it's not complete, what should follow after filter-branch --index-filter ? Thanks. – Cecilececiley

andik: try git filter-branch --tree-filter 'true;' --all. I think you will need tree-filter instead of index-filter because crlf conversion only happens on checkout (in other words: you need a worktree). 'true;' is just a dummy filter here which actually does not do anything – Heterogony

Answer 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.

Jesselyn

#23868814 - excellent. Thank you @e40! – Olfactory

Answer 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.

Fidele

I suggest to have this option ALWAYS to true on windows - you gonna run into lots of trouble with other plattforms if you actually don't. – Lesseps

this is not an answer relevant to "repair" – Olfactory