From: Segher B. <se...@ke...> - 2010-12-07 19:03:06
|
>> Yes, mswindows developers do have to consciously decide what to set >> autocrlf to. This can be seen as a shortcoming of git; it is nothing >> we can do anything about. > > I think I proved otherwise. I think you merely showed that yes, it is possible to mess things up. >> People just have to learn to use their tools. > > Agreed. But we can also avoid them learning more than they should. Not > everybody wants to be an expert on git CRLF conversion, or tax returns, > or whatever you are being constrained to learn because you're not given > any other choice. I don't think we'll ever avoid the need to learn tax > returns, but we can spare the requirement of learning git CRLF > conversion from top to bottom where a quick "if you're on Windows and > want to submit patches to us, use autocrlf. And if you patch > .ac/.am/.sh, please keep the files LF'd - but git will tell us if you > introduce CRs there anyway) And how is it easier to do special stuff to some files in our repo, which might or might not hide from the mswindows that they should have set autocrlf correctly, oh but you need to do this and that in these few cases; how is that easier then to tell them to set autocrlf *like they need to do for anything else they use git for*? "Plain" git already defaults to the correct setting, since that is the same for everyone; and msysgit *asks* you on install what to default to. >> Any kludges you can come up with to make things "magically work" will >> in the end just magically explode in your face (and worse, in the face >> of people who have nothing to do with the "problem" in the first place!) > > And so we've come to this. "I don't like your *solution*, and I cannot > find a default with it on logical grounds, so I'll just call it a > 'kludge' and dangle the idea of *potential* *future* problems that I am > unable to elaborate on, and that, had I analysed the solution properly, > would know are not going to happen" I am saying you have a non-solution to a non-problem. Any problems you have here are problems you created yourself; and the "solution" is not a full solution, and it *does* give maintenance headaches (what other files will we need to set what attrs on later?), and it *might* cause other problems (if nothing else, as you yourself have noted, this area is in flux in git; if your argument is "well it's not likely it will cause problems", I might even agree after thinking on it, but why would we even consider it). > Until then, I'll take the *proven* 3 different scenarios that I > experienced of non -crlf breaking things for LF files You proved that you managed to break things. If you can show that you have problems with sane environments, with sane workflows (that does not include copying files between LF and CRLF environments!), then of course we should fix something. > Why should my 3 *actual* "blow ups" have less importance than your > future potential unproven "blow up"? Because _you_ caused your own three problems, and _you_ would cause those future problems. Segher |