On Wed, Apr 16, 2008 at 04:20:27PM -0400, Avery Pennarun wrote:
quoted text
> On 4/16/08, Dmitry Potapov <dpotapov@gmail.com> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html