Re: crlf with git-svn driving me nuts...

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Apr 16, 2008, 20:39 UTC
Message-ID: <20080416203923.GH3133@dpotapov.dyndns.org>
In-Reply-To: <32541b130804161320w42c68bc2p9d838dc127a57027@mail.gmail.com>

On Wed, Apr 16, 2008 at 04:20:27PM -0400, Avery Pennarun wrote:

Show 17 quoted lines

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

> 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