We've got projects with a mixed userbase of windows / *nix; I'm trying to migrate some users onto git, whilst everyone else stays happy in their SVN repo. However, there's one issue that has been driving me slowly insane. This is best illustrated thusly (on windows) : $ git init $ git config core.autocrlf false -->Create a file with some text content on a few lines $ notepad file.txt $ git add file.txt $ git commit -m "initial checkin" $ git status # On branch master nothing to commit (working directory clean) --> Yarp, what I wanted $ git config core.autocrlf true $ git status # On branch master nothing to commit (working directory clean) --> Yarp, still all good --> Simulate non-change happened by an editor opening file... $ touch file.txt $ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: file.txt # no changes added to commit (use "git add" and/or "git commit -a") --> Oh Noes! I wonder what it could be $ git diff file.txt diff --git a/file.txt b/file.txt index 7a2051f..31ca3a0 100644 --- a/file.txt +++ b/file.txt @@ -1,3 +1,3 @@ -<xml> - wooot -</xml> +<xml> + wooot +</xml> --> Huh? ... $ git diff -b file.txt diff --git a/file.txt b/file.txt index 7a2051f..31ca3a0 100644 --> Bah... don't care! get me back to the start... $ git reset --hard HEAD is now at 4762c31... initial checkin $ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: file.txt # no changes added to commit (use "git add" and/or "git commit -a") --> ARGH! $ git config core.autocrlf false $ git status # On branch master nothing to commit (working directory clean) $ git config core.autocrlf true $ git status # On branch master nothing to commit (working directory clean) --> WtF? Why does it think in this instance that there is a change? It's CRLF in the repo, it's CRLF in the working tree, and the checkout in either mode ought to be identical ?? Now this is further compounded by the fact that users then typically tend to do a 'CRLF->LF conversion' checkin - *BUT* this will cause merge conflicts if another user actually made a genuine change (I.E. the removal of CR and the change are both treated as significant). Additional fun is caused because some editors 'touching' files that they actually haven't modified, leading to all these 'null' changes. This is a bigger deal for us than it ought to be, because we're pulling changes from a windows-based svn repo, which is always CRLF. Should I set core.autocrlf=input when doing 'git svn fetch' (and would it pay any attention)? Also is it possible to tell the diff / merge machinery that it ought to just ignore text file line endings when merging ? Sorry if some of this is stupid-user territory, but there's probably a few people out there also looking at trying to migrate away from Windows+SVN that are likely to hit the same things... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
