Menu
▾
▴
libusb-devel
|
From: Peter S. <pe...@st...> - 2010-12-03 14:45:35
|
Pete Batard wrote: > We're not writing software for us. We're writing it for our users. Open source is actually the other way around. Check the license. It's unfortunate that you continue to consider someone using git to be a user. (Currently they have no choice, but that must change with snapshots.) Someone new to both libusb and git have a lot to learn before they will be effective code contributors in the project, and as a general rule no we should not optimize for them if it comes at a cost. TortoiseGit is not what I would recommend to Windows users because it has been useless for me in other ways. I would recommend Git Extensions. That also includes msysGit however, which you say also has the issue, so I think it remains important that we actually understand the problem before saying that it is fixed in any way. -crlf is a backwards compatibility flag that means -text. I want to understand why some of your git tools ignore text+eol=lf before applying a -text workaround. The tools should not behave like that. It does not match my understanding of git config --help and man gitattributes. I hope you can investigate further since you're the only one seeing the problem? //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-03 16:59:31
Attachments:
config
|
On 2010.12.03 14:45, Peter Stuge wrote: > Open source is actually the other way around. Check the license. "AS IS" doesn't mean deliberately annoying to build for our users. The core of the (L)GPL is a minimal requirement ensuring that ANY user of the software have the ability to rebuild and run a modified version, and carry on the same rights for the next user. It's about providing them the complete freedom to do so. Now of course, developers can stop there - nobody is forcing them to go the extra mile. For instance, case they can produce something akin to the Nokia hotplug patch: "Here's a tgz of our modified source - we've filled the LGPL requirements, see ya". But as you yourself pointed out, going with the license minima is not a sane approach and this is now the kind of behaviour we want to encourage. Now, if you really want to stick to the Open Source license to the letter, as you seem to be willing to do here, then what right did you have to tell Nokia how they should have engaged with us, since they did fully comply with the license obligations? Well, the situation is very similar here. We can tell our users (I'll come to git users being 100% part of our user base) "if you want to build, just upgrade your tools, or sort out your default configuration", and we'll have filled our LGPL requirements, without the need to go a millimeter further, let alone a mile. But when we know precisely how to fix an issue that we suspect many users will potentially encounter, and it's a 10 seconds low impact fix (because, right, the possibility that someone might modify the .ac/.am/.sh in a DOS editor if we use -crlf and inadvertently reintroduces some CR/LFs should really take precedence over everything else - who cares about annoying TortoiseGit users now when we can ensure that no potential future developer will ever reintroduce a small issue, which we will either catch up during review, or at worst, fix in 30 seconds if reported), not doing it really makes us look like a bunch of pompous developers. The (L)GPL only sets the miminum requirements that ensure software freedom is respected by all the parties. If you start to see them as a target, you might as well switch to writing proprietary software IMO. > It's unfortunate that you continue to consider someone using git to > be a user. (Currently they have no choice, but that must change with > snapshots.) As I already pointed out last time you asked about this very item, as long a we have a a *public* git tree, then our users are *free* to use whichever method they want to retrieve the source. Some people like the stability of dot releases. Others like to be at the very edge. Now if you want to dismiss the latter category as developers who are not worthy of our consideration, because they're not approaching software development the same way as you do, better make that statement feature prominently on the libusb homepage, because this is a freedom restriction that they need to be aware of. Until then, I'm afraid this is open source. If you want to use our software, there's nothing in the LPGL that tells you to either not use specific flavours of git or pay the consequences. > Someone new to both libusb and git have a lot to learn before they > will be effective code contributors in the project, and as a general > rule no we should not optimize for them if it comes at a cost. 10 seconds patch != full fledged optimization. And once again: Open source gives you NO RIGHT to constrain how people can contribute to a project. If someone new to git and libusb experiences a bug in the Windows backend, I'd much rather they try to propose a patch than send a mail with "it doesn't work". Heck I'll even help them find their way with git, as I've done no later than yesterday with someone who wanted to test the hp branch. That's also how you ensure that everybody in your target audience has a positive experience with your software, and that the software is successful. Again, I'm really starting to have a problem about how exclusive and elitist you seem to be willing to turn libusb into. In my book, everybody who want to contribute to libusb is more than welcome, no matter the background. What's more, given our rate of releases, we're hardly in a position to place an entry level hurdles on libusb contributors. > TortoiseGit is not what I would recommend to Windows users because > it has been useless for me in other ways. And I'm going to tell you that, as far as I'm concerned, I found that TortoiseGit made my development more productive. You had a bad experience, I've had a good one (for almost a year now), and what's more, I'm proposing a fix to ensure that, if people still have a bad experience with TGit, it doesn't come from something that libusb could avoid. But sure, nobody should seriously be using TGit because you said so. > -crlf is a backwards compatibility flag that means -text. I want to > understand why some of your git tools ignore text+eol=lf before > applying a -text workaround. If you have time to waste with git (I don't), my git/config for libusb is attached. I had the same issue with libwdi (but libwdi initially branched of libusb), and I think I reinstalled Tgit/Msys-git from scratch at least once (probably twice) and the issue persisted. Currently, I'm using 1.5.2.0 (because it's been stable alright, and I haven't found the need to upgrade, I'll switch to 1.5.8.0 when I have nothing better to do). As for the underlying msysgit it's 1.7.1.msysgit.0. Again, if you're rejecting a *working* fix, then do propose something better that you have tested. If not, you should have enough flexibility as a maintainer to accept the fix, especially when maintenance operations are way behind schedule. But that's just my view of how I would approach it in your shoes. The project will not gain much from your becoming a git master, or reaching git enlightenment, if patches stay on the sidelines. > The tools should not behave like that. Yes it shouldn't. But it's not like people are not already aware that there's git's CRLF handling has issues [1]. After I searched this further (yesterday) and found the bit linked, I got even more convinced that the last thing I want to trust git to handle CRLFs, hence my push for us to have full control by applying -crlf, be done with it, and move on to something a lot more productive. > It does not match my understanding of git config --help and > I hope you can investigate further since you're the only one seeing the problem? I'm the only one who *reported* the problem, big difference. I wouldn't be pushing it so much if I didn't expect other TGit/Msys-git users to also have to experience the same issue. Again, as far as I'm concerned, I don't trust git one bit to handle CRLFs (wasted enough time with that already), and I want to be in control of the files that matter. In the branches that are under my control, I have now achieved these goals. Besides, if we switch to SVN tomorrow or another VCS, all the time spent figuring out that issue will be worthless. The fix I'm proposing is fine and it *WILL* address the issue completely (no need to overblow potential reintroduction of CRLFs when it can be fixed as easily). The only problem we really have with it that git zealots say it is not the "git way". I think we should establish a rule for libusb development. If you're spending too much time on pure git matters, as we've been doing way too much lately, then you're wasting everybody else's, and that's why this is the last reply you'll get from me on this matter. If I have to dos2unix my files when I use official branches, because you don't want to apply -crlf (would need it on *.sh, *.ac, *.am), I'll go through with it, because it'll still be less time consuming than the alternative. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-03 17:11:39
|
[1] http://kerneltrap.org/mailarchive/git/2010/3/9/25215/thread /Pete |
|
From: Peter S. <pe...@st...> - 2010-12-03 17:48:46
|
Pete Batard wrote: > when we know precisely how to fix an issue that we suspect many users > will potentially encounter, and it's a 10 seconds low impact fix .. > not doing it really makes us look like a bunch of pompous developers. The point is that it is a workaround for a problem elsewhere, and I would rather understand the problem than settle for a workaround that allows the same problem in the future. > Some people like the stability of dot releases. Others like to be at > the very edge. Why I think snapshots are important, and something we sorely miss, especially since there is a lot of work going on and no release for a while. > there's nothing in the LPGL that tells you to either not use > specific flavours of git or pay the consequences. No - that's just common sense. > Open source gives you NO RIGHT to constrain how people can > contribute to a project. Creating any work gives both you and me the right to constrain others. It's about tools; if the tools are used well, then contribution becomes very easy with git both for contributors and the project. > If someone new to git and libusb experiences a bug in the Windows > backend, I'd much rather they try to propose a patch than send a > mail with "it doesn't work". Me too! But it's not common, and I don't believe the reason is that git is a hurdle. > Heck I'll even help them find their way with git, Which is a great initiative! I think it makes a lot of sense to gather some git knowledge that we find useful on http://libusb.org/wiki/Development > I'm really starting to have a problem about how exclusive and > elitist you seem to be willing to turn libusb into. I think you misinterpret my intentions and assume the worst. > In my book, everybody who want to contribute to libusb is more than > welcome, no matter the background. Yes and no, because handholding can take a lot of time. But I certainly think that it is a good idea to have a reference for things that are relevant to those who use libusb and may want to help by sending code improvements. Anyone who feels like working on that kind of documentation, or any other kind of documentation, and does not yet have access to the wiki to do so please let me know and I will arrange access immediately. > What's more, given our rate of releases, we're hardly in a > position to place an entry level hurdles on libusb contributors. Because much is pending it is especially difficult to find resourcee for training new developers. >> -crlf is a backwards compatibility flag that means -text. I want to >> understand why some of your git tools ignore text+eol=lf before >> applying a -text workaround. > > If you have time to waste with git (I don't), A very difficult situation if you want to contribute but do not really care for learning the tools. > my git/config for libusb is attached. Hm. You set safecrlf explicitly. My git config --help doesn't say what the default is, but I don't think safecrlf=false can ever be harmful. But I think autocrlf=true explains why you need -text in your repo. I think whitespace=cr-at-eol is plain incorrect when working with libusb. It suggests that we would want CR in the repository, which isn't the case. Instead, we should use the tools, and git can handle CRLF conversion. Possibly we need to give it more accurate information (e.g. in .gitattributes) for it to work well, but -text is obviously not great for text files. > As for the underlying msysgit it's 1.7.1.msysgit.0. This is pretty recent so -crlf is only backwards compatibility also there. > Again, if you're rejecting a *working* fix, -text is a workaround, not a fix. > then do propose something better that you have tested. Normally I make it a point to do just that, but I can't really test a fix when I can't reproduce the problem. I have no Windows system. This is why I was hoping that you would investigate. > The project will not gain much from your becoming a git master, > or reaching git enlightenment, if patches stay on the sidelines. The project will gain in efficiency if all project members are git masters, as I think we should aspire to be, to the relevant extent for us each. Does that make sense at all? >> The tools should not behave like that. > > Yes it shouldn't. But it's not like people are not already aware that > there's git's CRLF handling has issues [1]. I think this link fell off? I'd be interested in reading it. > I don't trust git one bit to handle CRLFs So far I do, because it has been reliable for me, so I still think it's important to find out what it causing the problem that you see. > if we switch to SVN tomorrow or another VCS, all the time spent > figuring out that issue will be worthless. I actually don't believe there is another tool as good as git right now and there's no point in switching to something worse. > I think we should establish a rule for libusb development. If > you're spending too much time on pure git matters, as we've been > doing way too much lately, then you're wasting everybody else's, I don't think learning is ever a bad thing. > less time consuming than the alternative Of course learning takes time, and if time is of the essence then learning is actually dangerous in the short term. But I believe that learning starts paying off pretty quickly, and certainly is a net win in the long run. //Peter |
|
From: Michael P. <mic...@gm...> - 2010-12-04 00:53:47
|
Peter Stuge wrote: >> Pete Batard wrote: >> > my git/config for libusb is attached. >> >> Hm. You set safecrlf explicitly. My git config --help doesn't say >> what the default is, but I don't think safecrlf=false can ever be >> harmful. But I think autocrlf=true explains why you need -text in >> your repo. You have told us several times to set core.safecrlf=true, once privately to me in the beginning, and once to Orin here (which Pete responded to also): http://marc.info/?l=libusb-devel&m=126468835121169&w=4 But... I privately sent Pete this around Aug 2nd when .gitattributes were first changed: Michael wrote: > Hrm, well, maybe you can help me out here. I cannot get git to stop showing > me diffs against your master, and they're all > "whole-file-replacement-looking" things with the relevant files. > > $ git config -l |grep crlf > core.autocrlf=true > core.autocrlf=true > core.autocrlf=true > core.safecrlf=true > > Whenever I tell git to just overwrite the files with the ones from your > branch (like I sometimes do), it just tells me my working copy is clean > (nothing to do). But it still shows diffs. I'll try a few more things... As it stands, .gitattributes is still the only place I do not have any intention of mirroring Pete on, or at least not on certain lines (I can't remember if they were all a problem). It caused me a couple hours of trouble trying to fiddle with my repo and get it to work. Fortunately, I found some way to revert (well, reset), troublesome as even that was. I'd never had so much trouble with reset or checkout prior to that. I'm almost wondering if the situation is that we all have to have exactly the same settings, and that no one set is more forgiving than another? If that's the case (and it may not be), that would put to rest the argument about making git-users do more up front, since it could go either way. Peter wrote: >> I think whitespace=cr-at-eol is plain incorrect when working with >> libusb. It suggests that we would want CR in the repository, which >> isn't the case. Instead, we should use the tools, and git can handle >> CRLF conversion. Possibly we need to give it more accurate >> information (e.g. in .gitattributes) for it to work well, but -text >> is obviously not great for text files. Hrm, I also have this set. Could that be my problem, or did I misunderstand? Is it necessarily bad to have CR's in the repository? There are certainly some files that should be that way in the snapshot (and also some that should be LF-only in the snapshot). In particular, for the snapshot, I'd like to see the MSVC stuff, source files, and documentation as CRLF, and the bash/autotools/make-specific stuff as LF. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-04 02:40:05
|
> I'm almost wondering if the situation is that we all have to have exactly > the same settings, and that no one set is more forgiving than another? If > that's the case (and it may not be), that would put to rest the argument > about making git-users do more up front, since it could go either way. Everyone on unix systems has no problems. There are a zillion different kinds of mixed-up line ending things on mswindows; it certainly does not help that with git, changing your autocrlf etc. settings does not make your currently checked-out tree magically correct (you'll need to do a clean checkout for anything to make sense again, or so it seems). Ideally, the repo should work as-is for both unix and mswindows users if they both use tools with sane defaults. If we can get there, great! > Is it necessarily bad to have CR's in the repository? For text files? Yes, absolutely. For anything else? Nope, git is 8-bit clean. > There are certainly > some files that should be that way in the snapshot (and also some that > should be LF-only in the snapshot). In particular, for the snapshot, I'd > like to see the MSVC stuff, Yup, those files should be marked as binary -- we don't want to see diffs of big auto-generated XML-like files anyway. > source files, and documentation as CRLF, Dunno about those. It would be nice if other people could read them, and if they were the same format as everything else. > and the > bash/autotools/make-specific stuff as LF. I still don't understand why in your configuration those are checked out as CRLF, but other text files are just LF (or, why don't do these other files give similar problems?) Maybe you should check out _all_ text files as LF? Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-04 02:51:39
|
Segher Boessenkool wrote: >> Ideally, the repo should work as-is for both unix and mswindows users if >> they both use tools with sane defaults. If we can get there, great! Certainly, and if someone figures this out, I'll give it a shot again. But I haven't seen anything changed since I last discussed this with Pete four months ago. Not blaming anyone; just saying I haven't tried again. >> > and the >> > bash/autotools/make-specific stuff as LF. >> >> I still don't understand why in your configuration those are checked >> out as CRLF, but other text files are just LF (or, why don't do these >> other files give similar problems?) I haven't checked, but I presume some of those need to be LF. Leaving them LF doesn't help mingw/cygwin people as much, but the alternative is likely even worse. >> Maybe you should check out _all_ text files as LF? Eh, Linux editors/viewers seem smart enough. Some Windows editors/viewers/difftools are particularly brain-dead with regard to line endings. And I'm NOT really talking about development environments or compilers. Somebody just wants to LOOK at source/patch, or make a simple CHANGE to docs, and they can't use certain editors/viewers on Windows. Thus, anything that can be CRLF probably should be, since the other OSes handle non-native formats better. But see above for files that may need to be LF. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-04 03:04:37
|
>>> Maybe you should check out _all_ text files as LF? > > Eh, Linux editors/viewers seem smart enough. Most tools do not work, or don't work correctly, with CRLF line endings on unix systems. Even many editors/viewers do not (vim/emacs/less work more or less though). > Some Windows > editors/viewers/difftools are particularly brain-dead with regard to line > endings. And, presumably, you want to use those? Hrm. > Thus, anything that can be CRLF probably should be, since the other OSes > handle non-native formats better. No, they don't. And git expects plain LF for line-endings in the checked in repo, for things like its built-in diff, etc. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-04 03:19:49
|
Segher Boessenkool wrote: >> >>> Maybe you should check out _all_ text files as LF? >> > >> > Eh, Linux editors/viewers seem smart enough. >> >> Most tools do not work, or don't work correctly, with CRLF line endings >> on unix systems. Even many editors/viewers do not (vim/emacs/less work >> more or less though). What other editors or viewers do you need, aside from 2 of those 3? Fwiw, I specifically had emacs and less in mind. >> > Some Windows >> > editors/viewers/difftools are particularly brain-dead with regard to line >> > endings. >> >> And, presumably, you want to use those? Hrm. Yes, because if it weren't for this line-ending issue, they'd be the clear winner over anything else I've tried. I'm primarily thinking of notepad and windiff. Notepad loads in a split-second (not even noticeable, and not something I can say for vi or emacs, but analogous to nano), plus notepad is associated with a lot of files by default on Windows. Obviously, you don't use it to make serious source code edits, but, by definition, any serious edits make the load time a negligible overhead. I primarily have viewing in mind here, with either a viewer or editor. >> > Thus, anything that can be CRLF probably should be, since the other OSes >> > handle non-native formats better. >> >> No, they don't. I'm not sure about that. Linux has given me very little trouble keeping everything except Makefiles in CRLF. But, assuming you're right, at least those tools can be improved. >> And git expects plain LF for line-endings in the checked >> in repo, for things like its built-in diff, etc. Ok, that helps to know. This could be part of the problem I'm running into. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-04 03:38:37
|
>>> >>> Maybe you should check out _all_ text files as LF? >>> > >>> > Eh, Linux editors/viewers seem smart enough. >>> >>> Most tools do not work, or don't work correctly, with CRLF line endings >>> on unix systems. Even many editors/viewers do not (vim/emacs/less work >>> more or less though). > > What other editors or viewers do you need, aside from 2 of those 3? Fwiw, > I > specifically had emacs and less in mind. Classic "more" does not work correctly. "cat" does not work. "vi" does not work (and neither does vim in some configurations, and sometimes it guesses wrong (when you have unicode on the first line, in some cases, for example)). "grep" does not work. "diff" does not work. "patch" makes a mess. >>> > Some Windows >>> > editors/viewers/difftools are particularly brain-dead with regard to > line >>> > endings. >>> >>> And, presumably, you want to use those? Hrm. > > Yes, because if it weren't for this line-ending issue, they'd be the clear > winner over anything else I've tried. I'm primarily thinking of notepad > and > windiff. Won't notepad mutilate all files with a UTF marker at the start? > Notepad loads in a split-second (not even noticeable, and not > something I can say for vi or emacs, but analogous to nano), plus notepad > is > associated with a lot of files by default on Windows. Obviously, you > don't > use it to make serious source code edits, but, by definition, any serious > edits make the load time a negligible overhead. I primarily have viewing > in > mind here, with either a viewer or editor. So you want all source code (and other text files) to be checked out in CRLF; and the MSVC files as binary. And you do not care about Makefiles and configure.ac etc.? It sounds to me like the default config of msysgit should work fine for you. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-04 04:09:11
|
Segher Boessenkool wrote: >> Classic "more" does not work correctly. "cat" does not work. I just tried them now against a CRLF source file. I don't see any problems. What doesn't work for you? (sys-apps/util-linux-2.17.2 , sys-apps/coreutils-8.5 , respectively) I checked the sourcefile with hexdump -C |less for 0D 0A, just to be sure that the test was valid. >> "vi" does >> not work (and neither does vim in some configurations, and sometimes it >> guesses wrong I don't usually use vi[m], so that's possible. >> (when you have unicode on the first line, in some cases, >> for example)). Ok, I admit unicode is not really a concern for me. I can see how it would be for other people. >> "grep" does not work. How so? It works for me. Again, just tried it, and it found what I searched on. (sys-apps/grep-2.5.4-r1) >> "diff" does not work. "patch" >> makes a mess. Well, now you're getting into utilities that touch more than one file at a time. Do you mean with two different line ending styles now, or both CRLF? If the latter, diff works. I guess as long as I put that caveat there, I should point out that windiff works ok as long as the line endings match between two files. I rarely use patch, so I don't know there. >> Won't notepad mutilate all files with a UTF marker at the start? I have no idea. Never been a concern to me. I don't think Unicode belongs in source code, anyway. Maybe docs, but that's iffy... But keep in mind that most references to Unicode in the context of Windows are UTF-16 (always 2 bytes, no matter what is represented), so that would obviously make a mess of most files, since every other byte is 0x00 on average. >> So you want all source code (and other text files) to be checked out in >> CRLF; and the MSVC files as binary. text: yes. MSVC: Forced CRLF, particularly since CRLF may make the upcoming snapshot-generation script easier to write. The snapshots will be generated by Peter on his server, which is most certainly not running Windows. ;) >> And you do not care about Makefiles >> and configure.ac etc.? On Windows, I agree, and I believe there are enough other people testing on other platforms that I'm unlikely to be the first person to catch any problems on these anyway. >> It sounds to me like the default config of msysgit should work fine for >> you. Meaning specifically which settings of autocrlf and safecrlf? Recall that I mentioned Peter, from the very beginning, suggested setting those explicitly to true. So if you're suggesting I unset them, I'd like to hear more details. Keep in mind my configuration was working just fine for 7-8 months until the August .gitattributes patch came along. I guess I can also point out here that I don't recall the .gitattributes changes for the LF files being an issue. I'm only re-voicing my earlier concerns in order to make sure no one says "one .gitattributes patch fails to cause problems, so they must all be ok", particularly when it sounds like the patch isn't going to be accepted as-is. Thanks, Michael |
|
From: Segher B. <se...@ke...> - 2010-12-04 04:34:32
|
>>> Classic "more" does not work correctly. "cat" does not work. > > I just tried them now against a CRLF source file. I don't see any > problems. > What doesn't work for you? (sys-apps/util-linux-2.17.2 , > sys-apps/coreutils-8.5 , respectively) I checked the sourcefile with > hexdump -C |less for 0D 0A, just to be sure that the test was valid. Your "more" is just a symlink to "less". "Real" more will show a ^M. I cannot actually think how cat would do the "wrong" thing here; I thought I remembered it messing up, maybe it doesn't. >>> (when you have unicode on the first line, in some cases, >>> for example)). > > Ok, I admit unicode is not really a concern for me. I can see how it > would > be for other people. People use it to write their name, like in the copyright message, which usually is at the start of the file. >>> "grep" does not work. > > How so? It works for me. Again, just tried it, and it found what I > searched on. (sys-apps/grep-2.5.4-r1) grep 'something$' will not work because it considers the CR as a normal character. >>> Won't notepad mutilate all files with a UTF marker at the start? > > I have no idea. Never been a concern to me. I don't think Unicode > belongs > in source code, anyway. Those markers are not valid UTF, and I'm told notepad writes them all the time. I have no idea, I don't use mswindows. In the unix world, almost everyone uses UTF-8 these days, not ASCII or 8859-1 or things like that. >>> It sounds to me like the default config of msysgit should work fine for >>> you. > > Meaning specifically which settings of autocrlf and safecrlf? I don't really know. I'll ask some people from other projects that have mswindows users. > Keep in mind my configuration was working just fine for 7-8 months until > the > August .gitattributes patch came along. That's a pretty compelling argument that that patch was a mistake. But I'd like to hear more other people as well; let's solve this once and for all, not ping-pong between twenty different versions that all do not work for someone :-) Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-04 05:12:01
|
Segher Boessenkool wrote: >> Your "more" is just a symlink to "less". "Real" more will show a ^M. $ ls -l /bin/more -rwxr-xr-x 1 root root 30244 Jul 30 07:29 /bin/more $ ls -l /usr/bin/less -rwxr-xr-x 1 root root 124708 Jul 30 06:41 /usr/bin/less $ tar tjf /usr/portage/distfiles/util-linux-ng-2.17.2.tar.bz2 |grep more util-linux-ng-2.17.2/text-utils/more.1 util-linux-ng-2.17.2/text-utils/more.c $ tar tzf /usr/portage/distfiles/less-436.tar.gz |grep \.c$ less-436/brac.c less-436/ch.c less-436/charset.c less-436/cmdbuf.c less-436/command.c [...] less-436/tags.c less-436/ttyin.c less-436/version.c Maybe your 'more' is out of date? >> grep 'something$' You're right. Interesting. Shouldn't be a major obstacle to fixing this, given that the alternative with non-text (non-LF,non-CRLF) is to say "Binary file XYZ matches". I.e., there shouldn't be a problem treating CR as the end of the line, right? But I haven't looked at the source, so maybe it would be difficult... Thanks, Michael |
|
From: Segher B. <se...@ke...> - 2010-12-04 08:33:14
|
> Maybe your 'more' is out of date? It's ancient. It was just an example. You cannot seriously expect the unix world to accept /r/n as a newline everywhere, let alone generate it. >>> grep 'something$' > > You're right. Interesting. Shouldn't be a major obstacle to fixing this, Yes there is. The code already has special magic to guess at CRLF (and a flag to turn it off), but it is only enabled on DOS systems. This is not an accident, it's a conscious decision by the maintainers of grep. Note that you not only need to get grep "fixed", but countless millions of other unix programs. Well, you could get a lot of them in one go by getting a "fix" like this into glibc -- good luck with that! Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-04 12:49:55
|
Maybe I'm missing something, but I fail to see how applying -crlf (or -text) on the files we care about is not exactly the solution that we've been wanting all along. [1] "Unsetting the text attribute on a path tells git not to attempt any end-of-line conversion upon checkin or checkout. " In other words: "Move over git! I'll take care of line endings myself. And please make sure you don't touch them.", which seems to me like the exact solution we want. All we need to do is ensure the files we care about have the right line endings, and it won't matter who retreives files on which OS and with which tools. A .dsw retreived on any platform will have CRLF (provided it was checked in with CRLF, which should be the case if .gitattributes applied at the time of checking in) and a .sh will have LF. So UNIX people can package files for MS users, and life's just peachy. The only issue is if the same file *must* be CRLF in one environment and LF in another, but we have no such item. Our .sh/.am/.ac must be LF in all environments, and our .dsw/.dsp/.vcproj/.sln must (should?) be CRLF, so using -crlf on those sounds like the perfectly logical approach. Even Segher's statement that "git expects plain LF for line-endings in the checked in repo, for things like its built-in diff, etc." doesn't seem to be a big deal from my experience, as git will just see "\r" as an extra character at the end of the line (see [2] for an example), which is absolutely fine. As to not using tools that can handle a specific set of line terminators, I don't think that is something we should concern ourselves with, so long as users always get the files that matter with line endings that are set in stone. Michael, what happens if you clone my directory from scratch? Given the current .gitattributes [3] (I have a commit that adds *.am/*.ac that I haven't pushed in yet) and the fact that I made sure that the .sh's were LF'd and the MS projects files were CRLF'd, if you don't get the expected line terminators, then either something doesn't work about -crlf (or it can be overridden locally) or I something is wrong in my understanding of what -crlf/-text is all about. Regards, /Pete [1] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html [2] http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=02043e6e0e2f27fe1d4f2a43ad7c42d6cd8b04a3;js=1 [3] http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=.gitattributes |
|
From: Michael P. <mic...@gm...> - 2010-12-04 17:22:29
|
Pete Batard wrote: >> In other words: "Move over git! I'll take care of line endings myself. >> And please make sure you don't touch them.", which seems to me like >> the exact solution we want. Assuming it obeys your wishes. Are you sure it does? >> The only issue is if the same file *must* be CRLF in one environment >> and LF in another, but we have no such item. Agreed (yes, I saw Segher's more recent email). >> .dsw/.dsp/.vcproj/.sln must (should?) Don't know which, either: must vs. should. I haven't bothered to try them with LF. >> will just see "\r" as an extra character at the end of the line (see >> [2] for an example), which is absolutely fine. It seems not to be "absolutely fine", because it is causing git headaches for me. git diff and git status don't work right. >> Michael, what happens if you clone my directory from scratch? What do you expect to happen? I just tried it and it cloned (I have system-wide-enabled auto&safecrlf). So what? I can also go into my repo and say $ git checkout -b pm pbatard/master and that also works. My problem comes when I try to mix with my branches (i.e., collaborate, rather than ONLY checking your code out and using as-is). Like I said in another email, I try to overwrite some of my files with yours (git checkout with a filename argument), and git goes nuts. I also can't diff my files against yours, in spite of the fact that mine are checked out CRLF and yours are stored that way...git diff just shows a whole file replacement. Mine are probably stored in the repo with LF, and, if so, for some reason I've been unable to change that without breaking hings. --cached makes no difference to git diff in this context (not sure it should, but I tried). -b DOES make a difference (ignore whitespace in diff); it then shows no difference. All those things USED TO WORK. To make matters MORE confusing, while git diff always fails comparing the two branches, it only actually shows a "^M" when Pete's stuff is the right-hand diff argument, not the left one. Go figure. Maybe that's part of the "whitespace error" thing? It IS highlighted. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 00:00:02
|
(forgot reply to list on this one) On 4 December 2010 17:22, Michael Plante <mic...@gm...> wrote: >>> In other words: "Move over git! I'll take care of line endings myself. >>> And please make sure you don't touch them.", which seems to me like >>> the exact solution we want. > > Assuming it obeys your wishes. Are you sure it does? Been using it for months now on libwdi and libusb. Haven't seen any evidence of files being converted back by git. >>> .dsw/.dsp/.vcproj/.sln must (should?) > > Don't know which, either: must vs. should. I haven't bothered to try them > with LF. Same here. Preferred to be safe and anticipate issues (especially if snapshots are built on Linux), and being in control of line terminators on these files, rather than leave git do whatever it decides to do for reasons that you need to spend hours to figure out, sounds like the better deal to me. >>> will just see "\r" as an extra character at the end of the line (see >>> [2] for an example), which is absolutely fine. > > It seems not to be "absolutely fine", because it is causing git headaches > for me. git diff and git status don't work right. Yes, because we addressed the CRLF/LF issue late in the game, so obviously, if you already have a branch that didn't have .gitattributes, you will suffer until you convert the files. None of the source files should have been affected, because we didn't modify how git decides to mangle them in any way. >>> Michael, what happens if you clone my directory from scratch? > > What do you expect to happen? I just tried it and it cloned (I have > system-wide-enabled auto&safecrlf). So what? I can also go into my repo > and say > > $ git checkout -b pm pbatard/master What I was asking is: do you see CRLF on MS projs, and LF on .sh (and soon .ac/.am as well). > and that also works. My problem comes when I try to mix with my branches > (i.e., collaborate, rather than ONLY checking your code out and using > as-is). Again, the only problem is that we took measures against git's incomprehensible handling of line terminators in the middle of the game, and if you don't apply the same .gitattribute to your branches, and convert the files that need to be converted, you will have issues. I still see it as a better deal than the alternative, as you're the only one affected, and I'm pretty sure you can fix it easily. I'm not planning to add new files to gitattributes any other month. The .ac/.sh/.am were added because they were causing an issue, and the MS proj to be on the safe side. In all likelihood, this is a one off operation, that will ensure that anybody who branches from libusb in the future will not have to waste their time with terminations. Yeah, this was bad for you, but that's one against all our future contributors, and, AFAIK, if you understand what happened, you should be able to fix your branches. You'll have to recommit converted files, but I don't see it as a big deal on private branches. Also, merging the planned .gitattributes into mainline won't be an issue (as the MS proj files are not there yet, and the others are already LF'd). Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-05 04:44:05
|
Pete Batard wrote: >> Yes, because we addressed the CRLF/LF issue late in the game, so >> obviously, if you already have a branch that didn't have >> .gitattributes, you will suffer until you convert the files. None of >> the source files should have been affected, because we didn't modify >> how git decides to mangle them in any way. Except that, like I mentioned, I tried for several hours to convert them and get git to accept them. It would not. Since safecrlf is the only potentially-relevant setting of mine that differs from yours, I'm guessing that that may be the culprit. But I'm reluctant to turn it off until I hear what Peter has to say about the pros of safecrlf. >> What I was asking is: do you see CRLF on MS projs, and LF on .sh (and >> soon .ac/.am as well). When I clone your repo, autogen.sh has LF's, libusb.dsw has CRLF's. Ok? I'm not sure that was ever a problem. (Just FYI, and I don't really care, but that stands in contrast to my working copy of libusb-mplante.git, where everything is CRLF.) >> I'm pretty sure you can fix it easily. See above. I tried in August to fix it as soon as you pushed it. No luck. Unfortunately, I don't remember the details, and I don't have time to go through that exercise again (unless I'm somehow forced to, which is a choice that's ultimately up to the maintainers). I'm also don't see why it would succeed where it failed the first time. I guess I can try upgrading msysgit first. >> the MS proj to be on the safe side. And these are the only files that are giving me trouble (they are the only CRLF-only ones in your repo right now). The files you've marked LF-only do not give me any trouble. The files you've marked CRLF-only do. I'd like to figure out why, because I really do think the files you marked CRLF-only should be CRLF only (i.e., I agree in principle)...it just doesn't work right for me, as described previously (on and off list). >> Yeah, this was bad for you, present: is. not was. >> You'll have to recommit converted files, but I don't see it as a big >> deal on private branches. My recollection is that I tried to go back to the beginning, make the change, and rebase on top of it. But my memory is shaky four months later. It was something like that. I sure don't want all diffs across one commit to show everything changed (when it's not really). And why are private branches less of a big deal? (I think they're actually slightly MORE of a pain, but I won't bother you with the details, because the details are not really relevant to the discussion -- my point in this paragraph is precisely that private/public is a bit of useless trivia that has no substantive bearing on the matter.) Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 14:29:47
|
On 5 December 2010 04:43, Michael Plante <mic...@gm...> wrote: > And why are private branches less of a big deal? Private branches off a clearly flagged "EXPERIMENTAL" [1] branch are not a big deal, and never will be when the problems faced by those branches are not *logically* expected to find their way into official. Again, if someone wants to explain why they logically expect people cloning off official with -crlf on MS proj files to be affected, please do so. Myself, I have found no logical evidence that they will (I really don't see any scenario where they can, unless they have also use a pre 2010.08 branch of -pbatard, which is very very unlikely for anybody else but you now), and that's the reason why I stand where I stand. NB: to also answer Orin's, if the expectation is that MSVC will always be fine with non CRLF'd MS project files, I don't see an issue with removing the -crlf attribute on those. But I still fully expect that having -crlf will not cause issues to anybody else but Michael, which is why I'd advocate for safety. Regards, /Pete [1] http://libusb.org/wiki/windows_backend |
|
From: Michael P. <mic...@gm...> - 2010-12-05 18:22:15
|
Pete Batard wrote: >> On 5 December 2010 04:43, Michael Plante <mic...@gm...> wrote: >> > And why are private branches less of a big deal? >> >> Private branches off a clearly flagged "EXPERIMENTAL" [1] branch are >> not a big deal, and never will be when the problems faced by those >> branches are not *logically* expected to find their way into official. What about public branches off an "experimental" branch? In other words, you've subtly altered the subject here. I was asking public versus private, not "where did it come from". Regards, Michael |
|
From: Orin E. <ori...@gm...> - 2010-12-05 06:58:13
|
On Sat, Dec 4, 2010 at 4:00 PM, Pete Batard <pb...@gm...> wrote: > (forgot reply to list on this one) > > On 4 December 2010 17:22, Michael Plante <mic...@gm...> wrote: > >>> In other words: "Move over git! I'll take care of line endings myself. > >>> And please make sure you don't touch them.", which seems to me like > >>> the exact solution we want. > > > > Assuming it obeys your wishes. Are you sure it does? > > Been using it for months now on libwdi and libusb. Haven't seen any > evidence of files being converted back by git. > > > >>> .dsw/.dsp/.vcproj/.sln must (should?) > > > > Don't know which, either: must vs. should. I haven't bothered to try > them > > with LF. > > Same here. Preferred to be safe and anticipate issues (especially if > snapshots are built on Linux), and being in control of line > terminators on these files, rather than leave git do whatever it > decides to do for reasons that you need to spend hours to figure out, > sounds like the better deal to me. > Don't worry too much about .vcproj and .sln - Visual Studio doesn't seem to care about line endings in them. It also silently accepts source files with LF line endings. In fact, as far as I know and as has been noted elsewhere, the only standard Windows app that has a problem is Notepad. Orin. |
|
From: Segher B. <se...@ke...> - 2010-12-04 14:29:04
|
> Maybe I'm missing something, but I fail to see how applying -crlf (or > -text) on the files we care about is not exactly the solution that > we've been wanting all along. > > [1] "Unsetting the text attribute on a path tells git not to attempt > any end-of-line conversion upon checkin or checkout. " > > In other words: "Move over git! I'll take care of line endings myself. > And please make sure you don't touch them.", which seems to me like > the exact solution we want. Checked out text files should have the line endings your OS and tools expect, not what whoever checked them in prefers. > All we need to do is ensure the files we care about have the right > line endings, and it won't matter who retreives files on which OS and > with which tools. A .dsw retreived on any platform will have CRLF > (provided it was checked in with CRLF, which should be the case if > .gitattributes applied at the time of checking in) and a .sh will have > LF. Is that really what the various POSIX(-like) environments on mswindows expect? > So UNIX people can package files for MS users, and life's just > peachy. > > The only issue is if the same file *must* be CRLF in one environment > and LF in another, but we have no such item. Except all our text files, i.e. almost everything. > Our .sh/.am/.ac must be LF in all environments, Got proof of that? > As to not using tools > that can handle a specific set of line terminators, I don't think that > is something we should concern ourselves with, so long as users always > get the files that matter with line endings that are set in stone. You really want to punish all unix users because some mswindows users cannot sort out their work environment? And you really think that is acceptable? I'm perfectly happy about setting whatever weird attributes on MSVC project files, but please keep our precious shell scripts sane :-) I also would prefer not to have to set attributes on every second file in the repo, sigh. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-04 19:05:21
|
On 4 December 2010 14:28, Segher Boessenkool <se...@ke...> wrote: > Checked out text files should have the line endings your OS and tools > expect, not what whoever checked them in prefers. Again you misconstrue what I am saying. It's not a matter of preference. It's a matter that cygwin can't deal with CRLF'd .sh (and .ac), and Linux can't deal with CRLF'd .am.This is the problem we're actually trting to solve here, i.e. how do we prevent people from checking out libusb and have problems building it. Without -crlf, we can't, unless we start preventing the use of some git versions (and even then, I'm pretty sure people can screw up their options in Linux or cygwin, to end up with line terminators that they shouldn't have. >> All we need to do is ensure the files we care about have the right >> line endings, and it won't matter who retreives files on which OS and >> with which tools. A .dsw retreived on any platform will have CRLF >> (provided it was checked in with CRLF, which should be the case if >> .gitattributes applied at the time of checking in) and a .sh will have >> LF. > > Is that really what the various POSIX(-like) environments on mswindows > expect? It's what cygwin need, and if for any reason (copied the files from Windows or something) you have CRLF's in in your .am, you'll get errors on Linux to. Fact: autotools and scripts do not handle CRLFs without problems => we MUST have LF's always on these files, no matter the platform. Not a matter of preference, but a matter of preventing our users from wasting their time. >> So UNIX people can package files for MS users, and life's just >> peachy. >> >> The only issue is if the same file *must* be CRLF in one environment >> and LF in another, but we have no such item. > > Except all our text files, i.e. almost everything. Please re-read. Michael got it. >> Our .sh/.am/.ac must be LF in all environments, > > Got proof of that? Read my previous e-mails. I already told you guys the bad things that I saw happen iwth CRLF'd .sh/.am/.ac.. > You really want to punish all unix users because some mswindows users > cannot sort out their work environment? And you really think that is > acceptable? How is enforcing the UNIX default terminators on all platforms (for .sh/.am/.ac - it should be obvious that the .c/.h is not what I'm talking about here) punishing UNIX users? Seriously, please review the issue that prompted this discussion. As to the MSVC project files, if UNIX users want to edit them, they'd better make sure the line terminators used match the ones expected by the Windows tool, so again, no issue. > I also would prefer not to have to set attributes on every second > file in the repo, sigh. Same here, but for some files, we don't really have a choice, unless we expect everyone to be a git expert on CRLF conversion (which even git experts seem to have trouble with). Regards, /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-05 04:00:13
|
>> Checked out text files should have the line endings your OS and tools >> expect, not what whoever checked them in prefers. > > Again you misconstrue what I am saying. It's not a matter of > preference. The point is that what line endings _I_ get on _my_ system should not depend on what problems _you_ have with line endings on _your_ system. > It's a matter that cygwin can't deal with CRLF'd .sh (and > .ac), and Linux can't deal with CRLF'd .am. Neither system likes any CR. The Cygwin manual says this: "Binmode is the best choice usually since it's faster and easier to handle, unless you want to exchange files with native Win32 applications. It makes most sense to keep the Cygwin distribution and your Cygwin home directory in binmode and generate text files in binmode (with UNIX LF lineendings). Most Windows applications can handle binmode files just fine. A notable exception is the mini-editor Notepad, which handles UNIX lineendings incorrectly and only produces output files with DOS CRLF lineendings." > This is the problem we're > actually trting to solve here, i.e. how do we prevent people from > checking out libusb and have problems building it. You cannot prevent people from shooting themselves in the foot, and you shouldn't even try, there are always plenty of people who manage anyhow. > Without -crlf, we can't, unless we start preventing the use of some > git versions (and even then, I'm pretty sure people can screw up their > options in Linux or cygwin, to end up with line terminators that they > shouldn't have. And all evidence so far shows it causing more problems, and more bizarre problems, than it solves. Not good. > Fact: autotools and scripts do not handle CRLFs without problems => Fact: those are bugs. > we > MUST have LF's always on these files, no matter the platform. Fact: that does not work on every platform. It might be a suitable workaround for the aforementioned bugs on YOUR platform, but that is no reason to punish everyone else. >> You really want to punish all unix users because some mswindows users >> cannot sort out their work environment? Â And you really think that is >> acceptable? > > How is enforcing the UNIX default terminators on all platforms (for > .sh/.am/.ac - it should be obvious that the .c/.h is not what I'm > talking about here) punishing UNIX users? We now have to think about your strange workarounds and mark every new file we check in. This matters. It is the same issue as saying "we'll just write all file lists on one line", instead of figuring out what the problem is. It all adds up. It makes everything *more work* for everyone (but you), not less. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-05 14:13:34
|
On 5 December 2010 04:00, Segher Boessenkool <se...@ke...> wrote: > The point is that what line endings _I_ get on _my_ system should not > depend on what problems _you_ have with line endings on _your_ system. And once again we're hell bent ignoring that the problems I have are likely to affect EVERYONE who uses TortoiseGit/MSYS Git with the default parameters. Again, if I suspected I'm the only one who's going to be affected, I wouldn't bother submitting a patch. But when I suspected that MOST Windows contributors will be affected, it cannot be reduced to a simple view of "you're the only one affected - big deal" > You cannot prevent people from shooting themselves in the foot, and you > shouldn't even try, there are always plenty of people who manage anyhow. That line says a lot. If you see someone attempting to shoot themselves in the foot, you're just going to go on your way without even trying to intervene and say "oh well, that's life"? In this case, what you are proposing is akin to handling a loaded gun with the security off, while saying "well, there's no point in setting the security on, since people who want to shoot themselves will do it anyway". > And all evidence so far shows it causing more problems, and more bizarre > problems, than it solves. Not good. Not at all. We have reports from a single individual who cloned an *EXPERIMENTAL* branch and keeps a mix of branches that have conflicting settings, and then complain that the *EXPERIMENTAL* branch is not stable.They didn't manage to fix the problem they saw after they switched, and we (or at least I) have good reason to believe that only one individual will only ever be affected. You see "causing more problems" I see "one person having had one issue with an experimental branch, that I fully expect not to happen on official if the .gitattributes proposal is applied (see below)" >> Fact: autotools and scripts do not handle CRLFs without problems => > > Fact: those are bugs. Yes. So what? Doesn't make the argument any less valid. Unless the idea is that bugs on external tools that impact our users is not something we should care about ever. >> we >> MUST have LF's always on these files, no matter the platform. > > Fact: that does not work on every platform. Fact: your "Fact" is actually not a fact! Please point to the platform where having LF on .ac/.sh/.am doesn't work. If you can't do that, then please don't abuse "facts". The only files that are causing an issue, as pointed out by Michael, are the MS project files. Those are CRLF. And Michael himself pointed out that he had no issue with the LF'd file, which is exactly what I expected. > It might be a suitable > workaround for the aforementioned bugs on YOUR platform, but that is > no reason to punish everyone else. Again, WHERE exactly are we punishing users with LFs? The only person having a problem is with CRLF, because they are using branches that have different settings. This *WILL* not happen with official because both the CRLF files and the .gitattributes will be introduced at the same time, so nobody will be able to clone a branch off offiial where the project files are LF'd and then get a .giattribute applied. Therefore, the only people that can be affected are the ones who cloned from my EXPERIMENTAL branch before .giattributes was introduced on the project files. Well, sorry, but this is an EXPERIMENTAL branch, so things can change and/or break, and unless you can prove that your issue will be carried over into official (and I just explained why it won't), it's just not worth to spend more time than needed on a single individual's localized problem. Again: - not enforcing LF through .gitattributes => MANY users potentially affected - spending time figuring out why Michael's mixed .gitattributes branches (and eventually coming to the conlusion that the proposed .gitattributes *WILL* be a perfectly acceptable solution for official) => only ONE user affected. As much as I'd like to help Michael, I don't have the time for a problem that he logically will be the only one to have (unless someone creates a clone off my EXPERIMENTAL branch with a starting point prior to August, which is very very unlikely) Please feel free to come back to me when you have found evidence that the proposed .gitattributes will affect users of official (that aren't trying to merge with pre August versions of the Windows Experimental branch). And no, I am not dismissing the idea that there won't be people affected because I want to believe it. I dismiss the idea on the purely logical grounds of how I understand -crlf to work from reading the git documentation and what effects it will have on the various potential scenarios for users of the official branch. > We now have to think about your strange workarounds and mark every new > file we check in. every file != .sh/.ac/.am and MS project files. And this is not a "strange" workaround. Unless what you guys seem to be thinking this is not a half-assed "oh it works - let's not explore it further" but "it works, and I know exactly why it should work, and how it is not expected to cause further problems when integrated into official, so there's no need to waste more time on it" > This matters. It is the same issue as saying "we'll > just write all file lists on one line", instead of figuring out what the > problem is. It all adds up. It makes everything *more work* for everyone > (but you), not less. Again balance. The current solution you are proposing is to not use -crlf in .ac, which is the part that makes more work for EVERYONE (because now EVERY user of MSYS Git is likely to have to change their default options) rather than your "everyone" which only covers the libusb library developers. But sure, as always, our time is a lot more valuable than the time that's going to be wasted by ALL those guys. That's why setting all files on a single line is a perfectly acceptable workaround for me, as, we had good reasons to suspect this was an autoconf bug or limitation (which we found out it was), especially as you seem to have reiterated the idea that we don't want to concern ourselves too much with external tools bugs unless we have to. Sure, when we have time to waste, we can investigate, and that's what I'd usually advocate (we did just that for the libtool CJK bug), but when the issue is only cosmetic and we have better use for our time, I think pragmatism should prevail, and as such I for one will go with the pragmatic approach. Regards, /Pete |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X