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