13

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?

Community
  • 1
  • 1
Andik
  • 129
  • 1
  • 5
  • 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 – knittl Aug 26 '11 at 13:58
  • 1
    @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? – Andik Aug 30 '11 at 15:14
  • 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 – knittl Aug 30 '11 at 15:18
  • @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. – Andik Aug 31 '11 at 07:45
  • from the [git config manpage](http://www.kernel.org/pub/software/scm/git/docs/git-config.html): »This variable can be set to `input`, in which case no output conversion is performed.« – knittl Aug 31 '11 at 08:36
  • @knittl: I understand, but what input conversion will be performed? Ok, I'll try on some test repo, thanks. – Andik Aug 31 '11 at 11:30
  • input conversion should be `CRLF→LF` – knittl Aug 31 '11 at 11:42
  • @knittl: Hi again, I tried to use this command, but it's not complete, what should follow after `filter-branch --index-filter` ? Thanks. – Andik Sep 13 '11 at 11:22
  • 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 – knittl Sep 13 '11 at 19:48

2 Answers2

2

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.

e40
  • 397
  • 1
  • 11
  • https://stackoverflow.com/questions/23868314/git-merge-xignore-space-change-by-default - excellent. Thank you @e40! – TamusJRoyce Mar 10 '22 at 20:03
-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.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141