Re: crlf with git-svn driving me nuts...

["Nigel Magnay" <nigel.magnay@gmail.com>]

>  > The bit I really don't understand is why git thinks a file that has
>  > just been touched has chnaged when it hasn't,
>
>  Actually, it did change in the sense that if you try to commit this
>  file now into the repository, you will have a different file in Git!
>  So, it is more correct to say that Git did not notice this change until
>  you touch this file, because this change is indirect (autocrlf causes
>  a different interpretation of the file).
>

Okay - at the very least this behaviour is really, really confusing.
And I think there's actually a bug (it should *always* report that the
file is different), not magically after it's been touched.

But fixing that minor bug still leads to badness for the user. Doing
(on a core.autocrlf=true machine) a checkout of any revision
containing a file that is (currently) CRLF in the repository, and your
WC is *immediately* dirty. However technically correct that is, it
doesn't fit most people's user model of an SCM, because they haven't
made any modification. And if 1 person makes a change along with their
conversion, and the other 'just' does a CRLF->LF conversion, their
revisions will conflict at merge time. Blech. And because the svn is
mastered crlf (well, strictly speaking, it's ignorant of line endings)
this is gonna happen a lot.

Can't git be taught that if the WC is byte-identical to the revision
in the repository (regardless of autocrlf) then that ought not to be
regarded as a change?
Is there a way I can persuade the diff / merge mechanisms to normalise
before they operate? (e.g if core.autocrlf does lf->crlf/crlf->lf,
then an equivalent that does crlf->lf/crlf->lf before doing the merge
)?

In a perfect world I'd be able to switch all files int he repo to LF,
but that's not going to happen any time soon because of the majority
of developers, still on svn, still on windows.