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

On 7/30/08, Steffen Prohaska [off-list ref] wrote:

 On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:

quoted

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