On 7/30/08, Steffen Prohaska <prohaska@xxxxxx> wrote: > 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 -- 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
