Menu
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?
356
text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux. text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows.
Removed file merge conflicts To resolve a merge conflict caused by competing changes to a file, where a person deletes a file in one branch and another person edits the same file, you must choose whether to delete or keep the removed file in a new commit.
Git can handle most merges on its own with automatic merging features. A conflict arises when two separate branches have made edits to the same line in a file, or when a file has been deleted in one branch but edited in the other. Conflicts will most likely happen when working in a team environment.
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.
137
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
