Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set

From: Steffen Prohaska <prohaska@zib.de>
Date: Jul 30, 2008, 19:25 UTC
Message-ID: <56C07978-D6C9-4219-8B92-6217BD33F6D4@zib.de>
In-Reply-To: <32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com>

On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:

Show 17 quoted lines

> On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
>
>> What matters is that git gives you exactly back what you  
>> committed.  It
>> does so with core.autocrlf=true, unless you check out with a  
>> different
>> setting for autocrlf.
>
> You can tell that this statement isn't quite true because if you have
> a file with mixed LF and CRLF line endings, which I do (thanks,
> Windows!) then CRLF->LF conversion is not a reversible operation.
> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
> have a bare LF, and on such a subset of files, CRLF->LF is
> reversible).
>
> Also note that core.autocrlf=input is *definitely* not a perfectly
> reversible operation.

You are absolutely right. The files your describe are modified by git, because they are "invalid" text files, as git defines them. For git's autocrlf mechanism to work, a text file is only allowed to have a *single* type of line endings. Otherwise it is broken and git tries to help you fixing it.

Show 6 quoted lines

> And so here's the problem: svn hands you a file.  It may or may not
> have CRLFs in it, and the line endings may actually be a random mix of
> LF and CRLF, as I am actually experiencing at the moment in a
> particular repository at work.  If core.autocrlf is anything other
> than "false", git will modify the file, and git-svn won't be apply the
> diff on the next revision.

This sound like a specific problem with svn, not a general problem of git's autocrlf concept. I work with a git-only workflow and I never see the problems you describe.

Show 9 quoted lines

> It's conceivable that core.autocrlf=true will work if your svn
> repository is pure and svn hands you files only with CRLF endings.
> It's somewhat unlikely that most svn repositories are in that state
> (remember: it has to be perfect in *every revision* for git-svn to
> work).
>
> So anyway, I can't see how git-svn can possibly work in the general
> case if core.autocrlf is anything other than false *at git-svn fetch
> time*.

That might be the case. Note though that I cannot contribute much to this discussion because I never use git-svn.

Show 6 quoted lines

> And that's what I do, and it works great, modulo a bunch of
> stupid CRLFs that sneak into the repo via svn, but those can be fixed.
> Someday we'll stop using svn, and git-filter-branch can fix them all
> retroactively so that "blame" will work right.
>
> Perhaps git-svn needs to actually ignore the core.autocrlf setting?

 From what you describe, I get the impression that git-svn's handling
of line endings could certainly be improved.

	Steffen