crlf with git-svn driving me nuts...

From

Nigel Magnay <nigel.magnay@gmail.com>

Date

Apr 16, 2008, 19:10 UTC

Message-ID

<320075ff0804161210m46f3e83bpf7bf9d1d5816d914@mail.gmail.com>

  $ 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

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