On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:
On 7/30/08, Steffen Prohaska <prohaska@xxxxxx> 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.
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.
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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
