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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 30, 2008, 18:33 UTC
Message-ID: <32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com>
In-Reply-To: <80518F08-A9A9-4190-9AC4-D24DD6A1188B@zib.de>

On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:

Show 7 quoted lines

>  On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:
> > I think the real penalty is that with autocrlf enabled, Git no longer
> > stores exactly what I committed.
>
>  Git does *never* exactly store what you committed.  Git compresses
>  your data and creates packs containing many of your individual
>  files in a single pack.

This is not really an argument; making perfectly reversible changes as part of the storage process, then reversing them as part of the retrieval process, doesn't count as not storing what I committed.

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

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.

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

Have fun,

Avery