> > Nigel's example showed a few situations where git *thought* the file > > had changed when it hadn't, and yet is incapable of checking in the > > changes. > > Incapable of checking in? I have not found a single example in > his mail where it was impossible. The only quirk with autocrlf > is that you need to re-checkout your work tree after changing > it. There is no other problems with it as far as I know. > My (initial) setting of core.autocrlf to false was because that's what it was on all the windows clients (I know the default has now changed) and to make the later parts of the script obvious that the file in the repo had a CRLF ending, rather than have being converted to LF. That's the situation we have, because they've all come from SVN. The bit I really don't understand is why git thinks a file that has just been touched has chnaged when it hasn't, and doing a 'git reset --hard' actually doesn't help at all (but, bizzarely, git config core.autocrlf false & git config core.autocrlf true *does* !). The repo copy is CRLF, the working copy is CRLF, but git thinks it's changed... -- 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
