On Wed, Apr 16, 2008 at 04:20:27PM -0400, Avery Pennarun wrote: > On 4/16/08, Dmitry Potapov <dpotapov@xxxxxxxxx> wrote: > > In this case, you already have a file with the wrong ending, > > so file.txt will be shown as changed now, because if you commit > > it again then it will be commited with <LF>, which should have > > been done in the first place. > [...] > > If you do not want problems, you should use core.autocrlf=true > > on Windows. Then all text files will be stored in the repository > > with <LF>, but they will have <CR><LF> in your work tree. > > Users on *nix should set core.autocrlf=input or false, so they > > will have <LF> in their work tree. > > Alas, the subject of this thread involves git-svn, and the typical > git-svn user is someone who has no way of rewriting the existing > history in their svn repositories. Thus, files *will* be in the > repository that have the wrong line endings, and (as you noted) git > just gets totally confused in that case. Actually, what matters in what format files are in _Git_ repository. Maybe, there is a problem with git-svn and how it imports SVN commits to Git, but I have not encountered it. > 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. Dmitry -- 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
