On 4/16/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
quoted text
>  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.
[...]
quoted text
> 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.

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.

If all I had to do was checkout (thus converting everything to LF),
and then "git commit -a" to check in all the corrected files, then
git-svn would make one giant, very rude checkin to svn, and my
problems would be largely solved.  However, this does not seem to be
possible due to the problems you noted ("you are going to have
problems now").

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html