From: Pete B. <pb...@gm...> - 2010-12-06 17:45:20
|
On 2010.12.06 16:38, Peter Stuge wrote: > Pete Batard wrote: >> The premise here is that if a user ever gets a file that should not >> have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS >> proj), it's game over. > > But that's not really the case. That's our premise here. As Michael and I have pointed out, we don't currently have reason to believe MS tools cannot handle CRLF, but I can very imagine a scenario where MS decides to ditch XML in their *proprietary format* files and switch to full binary mode. These files are not supposed to be edited manually, so if they want to do so they can. Or maybe they just start with adding binary sections in there. In which case, what will git do if he still attempts to treat them as text? >> We don't know for sure that MS projs will ever be an >> issue, but one of the point of this thread is to assume so. > > When they become an issue we add text eol=crlf to .gitattributes. If this works with any settings for ____crlf, and when copying files over, then why not do it right from the start? > Said developer is doing it wrong. Ah "right" and "wrong". Who's to decide? You? >> Obviously, since it's been 6 months, he has forgotten everything >> about our one line advice not to copy repos. >> => game over > > No, game on. All files have LF, just as if the developer had done a > checkout on Windows using msysGit, without adding *crlf=true to his > configuration. No game over. If all files have LF, and the premise is that MSVC 201X does not accept non CRLF'd files, we have game over. Please don't ignore the premise when it becomes convenient for you to do so. If you want to ignore the premise, then half this thread can be ignored, as there's nothing we need to do for MS project files. >> Scenario 2: >> - Windows developer, libusb, git version >> - diligently reads our wiki page, and applies the *crlf=true to that he >> gets CRLF'd files. If the configure.ac text eol=lf works, he is supposed >> to get LF'd files there. So far so good. >> - later down the line, while using another git repo, he decides to >> change his *crlf *options* (why not - if we can advise a set of >> *options*, others can advise theirs. > > The settings are per-repo, not system-wide. > > >> (as I understand from Michael, local git repo settings can get overridden) > > It's the other way around, local repo settings override --global. OK, then maybe he set ____crlf as global originally and didn't set them in his repo, then changed the global settings again later on. So now, we have to guide them to make sure that they set their settings locally. For non GUIs that's easy, but we'll also need to mention GUI versions of Git. So I guess our little: "Please make sure that you set your ____crlf settings to true if you're on Windows," needs to be amended "and make sure you set them locally" and broken down further on how to do that depending on whether you are using to use commandline, TGit, and possibly git extensions. These options are fairly explicit (don't know about git extensions), but still, we need to highlight them if we want to be safe. >> Right now, because he modified them globally with that other >> project, > > What did he modify? A file with text eol=lf in .gitattributes? No, ____crlf. > If patches were sent to the > mailing list as they should, people will have noticed and pointed it > out. This is a scenario for a developer using libusb, not someone interested in sending us patches. What I'm concerned with here is avoiding that developer from finding an error and having to fix it on their own, as they will if they copy over their .ac/.am/.sh. It took me quite a while to figure out that the .am error I kept having when copying my files over to Linux for testing was due to CRLF... > Yep, this can happen if he keeps his own tree without sharing patches > with anyone else. Why should he? He's developping his application using *unmodified* files that he got from git. There's nothing to submit back. > He should remember to clone rather than copy; doing it wrong. Yes, people are really so silly not to know how they are supposed to use git, especially when git is the least of their concern, and they might be using a completely different VCS on a daily basis, and all they want to use is a library in their projects. > I simply assume that anyone using git to work with the source will > take a little while to learn about git before/while doing so. And I postulate that this is by no means something we need to enforce, and that we can instead free up time for our users for more productive activities than learning about git, especially if git is not their prime VCS. Not everybody uses git, not everybody should use git, and therefore, people should not have to spend time they don't need to spend learning the idiosynchrasies of git CRLF when we CAN avoid them to. >> => game over > > No, also game on. (...) and at some point either that patch will be > sent to the list, Again, if people have to send a patch to the list, which is not part of my scenario at all, it is very much game over. You still made somebody waste their having to fix a problem that we could ensure would not happen. >> If you want to dismiss those scenarios as far fetched, fine, but we >> happen to know that we can address them both with -crlf, > > Except that the files are text and should have LF line endings, so > telling git -text doesn't make sense Unless you consider that what -text does is ensure that no conversion is ever perform on the file, and we know for certain that there isn't a single platform where we need something different from LF, as is our case. > when text eof=lf is more accurate. Provided your ____crlf options are set as they should, which is not something we can enforce, only advise. People are free to ignore advice - happens all the time, and we have the opportunity to make sure we enforce the rule we need so that even if they ignore our advice, it won't matter. > You may see it as waste of time, but I do not, and I don't think > anyone should. Learning to use tools is only a waste of time if > there's no desire to use the tools What you fail to understand is that we do have a solution that doesn't require our users to learn about specific aspects of the tools. Therefore, yes, forcing them to learn IS a waste of their time. It is unneeded, and, again, if they mostly use a different VCS system, knowing CRLF settings from git won't bring them anything in the long run (apart from maybe thinking "wow, git sure does restrict what I'm allowed to do with my settings and how I can move files around - If I have to chose a VCS in the future, I'll make sure I steer well away from one that restricts me so.") Regards, /Pete |