Re: [Libusb-devel] CRLF in files checked out on Windows

[Peter S. <pe...@st...>]

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.

Whose premise? In any case the premise is not accurate.


> > Said developer is doing it wrong.
> 
> Ah "right" and "wrong". Who's to decide? You?

For the purpose of libusb, sure. But I guess that you will find the
same if you ask the developers of git.


> >> 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.

Please don't ignore again what I'm now writing for the second if not
third time; if that is something we encounter in the future, then
we'll add -text in .gitattribute for the files. But as long as they
are text files it is better to treat them as such.


> >> (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.

Actually no, we don't need to do that at all. Maybe you think it is
important but I am opposed to having a tutorial for various git user
interfaces on libusb.org. The information is readily available
elsewhere and someone using git to get libusb has a responsibility to
learn a bit of git on their own. I'm happy to add neccessary
commands to show how to use git, but not to add instructions for GUIs.
(If someone else does it of course I won't delete anything.)


> > 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.

If they have an issue with CRLF in source files while writing a USB
device driver I think there is something more serious going wrong.


> 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...

Would suggest asking for help on the mailing list or on IRC in case
of trouble like that. Most people do. Someone usually replies quickly
with useful hints.


> > 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.

If there are no modifications then the issue is moot.


> > 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.

Either they want to use git, or they don't. If they do, then they
should learn what is neccessary to use the tool. If they don't, then
maybe we can give them another option that fits better, such as
snapshots.


> Not everybody uses git, not everybody should use git,

We will not have workarounds for the case when such people use git
anyway.


> people should not have to spend time they don't need to spend learning 
> the idiosynchrasies of git CRLF

If they are using git and they care about CRLF then they should,
actually.


> > when text eof=lf is more accurate.
> 
> Provided your ____crlf options are set as they should,

No, the eol attribute takes precedence over other indicators. I tried
to explain this in previous messages. I'm sorry if it wasn't clear.
See git config --help for core.autocrlf.


> 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.")

It is very much a matter of understanding the tool. You seem
unwilling to understand git, but hopefully others who use it
are not.

Git is a significant help with the mess of platform-specific line
endings. If this is not clear, then I think everyone is happier if
the people in question do not use git at all. And perhaps we can
provide them an alternative which suits them better. Like snapshots.
Or something else. Any ideas?


//Peter