On Wed, Jul 30, 2008 at 12:25 PM, Steffen Prohaska <prohaska@xxxxxx> wrote: > > 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 all I care, git can consider the files as binary, but by *default* I should get back the same as I put in. [For the rest of my rant, I am referring to the default configuration of autocrlf on windows] > For git's > autocrlf mechanism to work, a text file is only allowed to have a > *single* type of line endings. Git's autocrlf mechanism can be a nice feature. But by default it should not be on (even on windows) because it can modify screw up my files. To be clear: when I say "git checkout" I want to get EXACTLY the same bits as went in when I did "git add" and "git commit". Any other default is broken. > Otherwise it is broken and git tries to > help you fixing it. My files were NOT broken when I put them into git. I committed them known good state. If msysgit changes them by *default* , then msysgit is broken. IF you are working on a cross platform project, then setting autocrlf on windows might be nice. But having it on by *default* is broken. Thanks, Tarmigan -- 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
