Menu
▾
▴
libusb-devel
|
From: Michael P. <mic...@gm...> - 2010-12-06 23:19:44
|
Pete Batard wrote: >> On 2010.12.06 12:51, Peter Stuge wrote: >> > Do you seriously consider it a problem to push and then pull, in >> > order to do that testing? Really? >> >> As I explained, if need to push a change on my public repo before I can >> pull it to test it on Linux, and then find that my change breaks Linux, >> you'll get another "oops!" commit. Temporary branch. Then kill that branch when you've finished testing. Or mark the commit as "this will go away" or something, and follow through even if the test works. Or, if you have a way to either see your Windows files from Linux or vice-versa, you can have more than one place to push/pull from, and do it without going through libusb.org's site. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-06 13:03:45
|
> It really sucks bigtime that MSYS autoconf can not handle CRLF. :( Yes, and someone who cares about msys should figure out what is happening there. It makes no sense at all to have some workarounds for something that might or not be abug, is not even understood by us, that will affect everything and everyone. Are normal source files (say, C text) in msys LF or CRLF? > Changing crlf settings in git never makes it change what is checked > out. Yeah. You have to do a fresh checkout if you change settings that change what a checkout will look like. Git does not track what settings were used for the checked out files (or the index). > Cygwin is *NOT* Windows. So using a Windows tool such as TortoiseGit > or msysGit to check out something that will be used Cygwin is not > correct, should not be expected to work, and must not be optimized > for. Make sure to use a Cygwin tool for Cygwin testing. I guess LF > may be the native line ending in Cygwin, which would explain why > Xiaofan never has problems with line endings. That is my understanding as well. Segher |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 13:44:09
|
On Mon, Dec 6, 2010 at 9:03 PM, Segher Boessenkool <se...@ke...> wrote: >> It really sucks bigtime that MSYS autoconf can not handle CRLF. :( > > Yes, and someone who cares about msys should figure out what is > happening there. It makes no sense at all to have some workarounds > for something that might or not be abug, is not even understood by > us, that will affect everything and everyone. > I think you guys have some mis-understandings about MSys and autotools. Firstly you should actually call them MinGW autoconf and not MSys autoconf. MSys autoconf is to created MSys dependent applications and this is not what we want, we want to create Windows native binary. Secondly MSys still use shell scripts similar to Unix and Cygwin, you can call it a mini shell environment but nevertheless, it is similar to Unix and Cygwin when it comes to shell scripts. If you ever use MinGW/MSys, and open the include files or the shell scripts (many under the bin dir are shell scripts), you will notice they are not CRLF. If you think CRLF is native and MinGW/MSys is Windows native and thus should use CRLF for everything, then you are totally wrong. -- Xiaofan |
|
From: Segher B. <se...@ke...> - 2010-12-06 18:59:44
|
>>> It really sucks bigtime that MSYS autoconf can not handle CRLF. :( >> >> Yes, and someone who cares about msys should figure out what is >> happening there. It makes no sense at all to have some workarounds >> for something that might or not be abug, is not even understood by >> us, that will affect everything and everyone. >> > > I think you guys have some mis-understandings about MSys > and autotools. Probably. I don't use mingw/msys, most of us don't. > Firstly you should actually call them MinGW > autoconf and not MSys autoconf. MSys autoconf > is to created MSys dependent applications and this is not what > we want, we want to create Windows native binary. So msys is a bit like cygwin, and mingw is native mswindows? > Secondly MSys still use shell scripts similar to Unix and > Cygwin, you can call it a mini shell environment but nevertheless, > it is similar to Unix and Cygwin when it comes to shell scripts. > > If you ever use MinGW/MSys, and open the include > files or the shell scripts (many under the bin dir > are shell scripts), you will notice they are not > CRLF. > > If you think CRLF is native and MinGW/MSys > is Windows native and thus should use CRLF > for everything, then you are totally wrong. Okay. So what _is_ correct line endings for mingw and/or msys? Just LF on everything? I looked at a lot of projects today that use git and supposedly can be built on mingw or msys; _none_ have anything special for line ending mentioned in .gitattributes. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-06 19:16:57
|
On 2010.12.06 17:44, Segher Boessenkool wrote: > So what _is_ correct line endings for mingw and/or msys? Just LF > on everything? Correct. /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-06 20:04:56
|
>> So what _is_ correct line endings for mingw and/or msys? Just LF >> on everything? > > Correct. So we don't need a .gitattributes at all; at most we need to advise people to keep core.autocrlf off for our trees. (And of course you can do whatever you need for the MSVC project files). Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-06 21:17:58
|
On 2010.12.06 20:04, Segher Boessenkool wrote: > So we don't need a .gitattributes at all; at most we need to advise > people to keep core.autocrlf off for our trees. Or, instead of hoping that everybody will read/do what we want them to do with git (which is a big if - we don't have that amount of control), we can enforce LF, since it neither pollutes our repo and leaves ALL git users free to set ____crlf as they wish, and still be able to clone and copy files between envs if they so chose. We happen to know that there's not a single platform where we don't need LF on .sh/.am/.ac, we don't expect that there will ever be, and with a 30 seconds patch that doesn't even change files from a repo that some people want to keep CR free, we can ensure that even if people screw up their ____crlf, our .ac/.am/.sh will still work... Yet, we don't seem to want to do that on the philosophical grounds that this is not the git way, that inexperienced git users are none of our concern, and that these people should go learn git in the first place if they want to use libusb. Again, please name a good reason why we shouldn't enforce LF on .sh/.ac/.am, as I don't find "But it forces some platforms (UNIX) to use the exact same line endings as the one they already use" very compelling. It's not because a file is not flagged as text that git can no longer handle it. If having LF files committed to the repo with -text/-crlf is is expected to cause issues, then please elaborate on them, as this is not what I've seen in my branch. So far, the only argument I'm hearing is "but we should use text always" on principle, rather than logic. Therefore I see it as matter of privileging us "we might introduce CRLF by mistake", when we are supposed to know better (as per Peter's "if you care about libusb you are supposed to care about CRLF") and we'll see the "\r" in the diffs, vs. inexperienced git users who might modify their options and end up with CRLF'd .sh/.ac/.am that prevent them from building libusb. Now, if you want to go executive on the decision to not help such users, that's fine, but you then need to be upfront and explicit about it, because it goes in direct conflict with the principles that *I* expect from an open source project, which is *ensuring* that our users have the freedom to use the source (which includes .sh, etc) in any way they want, and that includes copying files around or change options from tools -git- that are not, and will never be, under our control... Regards, /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-06 21:22:33
|
>> So we don't need a .gitattributes at all; at most we need to advise >> people to keep core.autocrlf off for our trees. > > Or, instead of hoping that everybody will read/do what we want them to > do with git (which is a big if - we don't have that amount of control), > we can enforce LF, Why would libusb do this, when no other project does? What is so special about libusb here? Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-06 21:38:33
|
On 2010.12.06 21:22, Segher Boessenkool wrote: >>> So we don't need a .gitattributes at all; at most we need to advise >>> people to keep core.autocrlf off for our trees. >> >> Or, instead of hoping that everybody will read/do what we want them to >> do with git (which is a big if - we don't have that amount of control), >> we can enforce LF, > > Why would libusb do this, when no other project does? > > What is so special about libusb here? This is not in the absolute (and there's nothing special about libusb, except the fact that we have 2 valid alternatives). This is as opposed to the alternative of not forcing people to find out that autocrlf will only work to a certain extent, and that they must also apply safecrlf under our conditions, vs enforcing -crlf on .sh/.ac/.am and leaving people not having to care one bit about the line terminators for these files, even if they use weird ____crlf settings. We know how to ensure that people have the freedom to change their ____crlf options if they so chose. Why then would we want to restrict that freedom? If we want to go that way, we might as well ask them to download some software that runs on their computer and prevent their ____crlf options from ever being set to settings we do not want them to use. I see it as restricting our user's freedom to use our software as they see fit. When we don't have an alternative, it is of course acceptable to restrict our users choices with such requirements as "use autoconf >2.65" (alternative would be for someone to spend time ensuring that 2.64 etc works, which nobody has done). But here we do have a known alternative, which is logically expected to give our users more freedom (copy files between envs and have the software still able to build), yet *chose* not to apply it, i.e. voluntary restriction of our users' freedom. Regards, /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-06 22:31:30
|
>>>> So we don't need a .gitattributes at all; at most we need to advise
>>>> people to keep core.autocrlf off for our trees.
>>>
>>> Or, instead of hoping that everybody will read/do what we want them to
>>> do with git (which is a big if - we don't have that amount of control),
>>> we can enforce LF,
>>
>> Why would libusb do this, when no other project does?
>>
>> What is so special about libusb here?
>
> This is not in the absolute (and there's nothing special about libusb,
> except the fact that we have 2 valid alternatives).
Dunno what you mean here, "two alternatives"?
> This is as opposed
> to the alternative of not forcing people to find out that autocrlf will
> only work to a certain extent, and that they must also apply safecrlf
> under our conditions, vs enforcing -crlf on .sh/.ac/.am and leaving
> people not having to care one bit about the line terminators for these
> files, even if they use weird ____crlf settings.
People will need exactly those same settings for any other open source
project hosted in git, including a bunch that go out of their way to
support MSVC as well. They're also the default settings for git, as
far as I can see.
Also, users who do not know this stuff are much more likely to use
tarballs / zipfiles anyway, as has been pointed out to you a lot of
times already.
> We know how to ensure that people have the freedom to change their
> ____crlf options if they so chose. Why then would we want to restrict
> that freedom?
Exactly similarly, we can limit all our source files to have lines of
at most 40 chars, so they can be displayed on a C64; or get rid of all
{}[] in C code since not every printer has those chars. According to
you, this would be "not restricting freedom", and requiring a sane
environment would be "restricting freedom".
> But here we do have a known alternative, which is logically expected to
> give our users more freedom (copy files between envs and have the
> software still able to build),
Copying files around like that does not work, has never worked, and will
never work. It's why programs like "d2u" and "recode" exist.
Segher
|
|
From: Pete B. <pb...@gm...> - 2010-12-07 11:59:23
|
On 2010.12.06 22:31, Segher Boessenkool wrote: > Dunno what you mean here, "two alternatives"? * eol=lf / eol=crlf and running the risk of having it overridden and people not getting lf'd files if they use MSYSgit whose defaults are autocrlf=true, safecrlf=false, as advocated by Peter During my tests with the supertest branch, I found that eol=lf could be be overridden by such settings, and Michael has also found that eol=crlf could be overridden depending on how you switch branches. * -crlf and always getting these files as LF/CRLF > People will need exactly those same settings for any other open source > project hosted in git, It's not because other people do one thing that we should follow suit, when we can fix a potential issue that they don't seem to either be aware of, or be willing to fix. > Also, users who do not know this stuff are much more likely to use > tarballs / zipfiles anyway, as has been pointed out to you a lot of > times already. Then you are discriminating. People who don't use tarballs can have problems that we know how to fix. As I said, because producing snapshots can take a while, people are expected to use git if they are interested in a feature that is not yet in a snapshot. I'd rather people be in a position where they can help us test libusb by using git, than have them wait for a tarball to identify issues. And actually, if the tarball line ending format is the format we actually want, why then don't we enforce it in git? If we don't provide tarballs and then expect users to go through a conversion, why then should we provide the files from git in one format, and then expect git to apply some conversion. The only files that might need conversion are the .c/.h, because we expect people to use them in editors that won't be able to handle a specific line terminator if we enforce one. This does not apply for .ac/.am/.sh and MS project files, as there is only ever one set of line terminators that should be applied to those. Even as they are text, if we know, as we do, the line ending format that we want for these files, git has no business whatsoever to convert them. None. So far, the only reasons for rejecting -crlf I have seen are: - *you* don't want CR in the repo - *you* don't want to constrain LF, even as we know that we want LF on some files always, as it avoids issues. Now, and this is also the important part that you may have missed, my tests at the time (supertest) showed that even with eol=lf, one could get CRLF on the files that should be LF (.sh), and this is why I believe that -crlf is the only approach that will work. I will test it again when I have a chance, just in case I got it wrong, but I *have* seen eol=lf fail to produce LF, the proof of that being that I went with -text in supertest [1] -> [2]. Had I found that eol=lf worked, that's what I'd have used. This is why, no matter what Peter says, I do NOT trust eol=lf to solve our problem, and I do believe that people will run into problems with it that will not occur if we use -crlf. The only reason to reject -crlf right now is some wishful thinking that what I've seen in supertest was just a fluke, and that eol=lf does actually work always. Maybe Peter is confident in git's line conversion, but, from experience, I'm not, and as far as I know, Michael also has found reasons not to be either. > Exactly similarly, we can limit all our source files to have lines of > at most 40 chars, so they can be displayed on a C64; Except nobody is expected to read our code on C64. People are expected to want to transfer files from on env to another, because there is a perfectly plausible scenario for it (UNIX <-> Windows, with one machine not having internet access). Oh, and I can come up with a C64 scenario if you want to go that far: Let's say someone in an impoverished country is trying to get into computing, and all they have is a C64. They are very eager to learn, and they have heard of this very cool project called libusb, which is of great interest to them. Somehow they managed to get the source. Well, if there exists a 30 seconds fix to get 40 chars formatting, and we expect our user base to be OK with it (which is the only part where this scenario is implausible because cutting at 40 is expected to penalize every other user of libusb), I wouldn't see a problem in implementing such a fix, because it helps people exert their freedom to copy, use and modify the source of libusb in any way they see fit. Now if the fix takes much longer to implement, and/or will penalize other users by restricting their freedom to use the source as they see fit, of course it wouldn't make sense. So far, the only person that has found any problem in going -crlf is Michael, but that was on CRLF files (not .ac/.am/.sh), and if you look at the commit that Michael failed to apply, it really looks like a git issue, because there's nothing in that commit that is expected to cause a problem that git shouldn't know how to handle: We just turn files to -crlf and we convert them. As such I am confident that, if we don't convert files, as wouldn't be needed for official, nobody will experience Michael's problem. And as Michael pointed out, he didn't have an issue with -crlf on .sh. > Copying files around like that does not work, has never worked, and will > never work. Not when the files only need to have one type of line termination always. The only problem is with dumb editors, but when a file must have the same line terminations on all platform, then unless you are using ftp in text mode (bad idea - it's the same as using git to do the conversion for you), so copying files around does work. Again there's no platform I know of where a shell script doesn't need to be LF'd. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=73bba959b695fabbe679b3754917ed919218b55d;js=1 [2] http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=d5032f4e537ddf5636b78238e2266261935c4b84;js=1 |
|
From: Michael P. <mic...@gm...> - 2010-12-07 12:39:27
|
Pete Batard wrote: >> if they use MSYSgit whose defaults are >> autocrlf=true, safecrlf=false, as advocated by Peter Two different things. Yes, those are defaults, no they are not advocated by Peter. Peter said to use safecrlf=true on Windows (at least to you, Orin, and me). >> During my tests with the supertest branch, I found that eol=lf could be >> be overridden by such settings, and Michael has also found that eol=crlf >> could be overridden depending on how you switch branches. >> * -crlf and always getting these files as LF/CRLF To be clear, I have no reason to believe this is necessarily a consequence of eol=crlf. It may well be that all .gitattributes are broken in this way, including -text. Unfortunately, it'd take time to come up with a test of this. >> > People will need exactly those same settings for any other open source >> > project hosted in git, >> >> It's not because other people do one thing that we should follow suit, >> when we can fix a potential issue that they don't seem to either be >> aware of, or be willing to fix. I don't necessarily agree/disagree with Segher here on the whole. However, this whole "let's do what everyone else does" mindset is slightly annoying. Particularly since that eol attribute was only introduced in May, it seems. Maybe no one else has bothered to follow up on new features (having had this discussion when different features were available), or maybe no one else cares enough, or maybe no one else has the same priorities, or maybe they were using a different VCS and that affects things in some way. Let's make the decision ourselves, rather than copying someone. It's of course fine to learn from others' tricks and tips, but evaluate rather than blindly copy. >> Segher wrote: >> > Also, users who do not know this stuff are much more likely to use >> > tarballs / zipfiles anyway, as has been pointed out to you a lot of >> > times already. And this could be the snapshot solution. LF in tarballs, CRLF in zipfiles. Slightly more work writing the script, but not too bad? >> And actually, if the tarball line ending format is the format we >> actually want, why then don't we enforce it in git? That was initially my point in even suggesting that CRLF be forced even when autocrlf is off. I am perfectly fine expecting git users to set autocrlf properly, but I think that the snapshot needs to be configured properly. If Peter (the eventual script author, afaik) would prefer to unix2dos files, rather than messing with eol=crlf in .gitattributes, that suits me just fine. But I'd like to see one or the other. The eol=lf for .sh/.ac is a completely separate issue, and one that I think only Segher and Xiaofan think doesn't need to be solved. Pete seems to prefer -text, and everyone else, eol=lf. But eol=lf is motivated by a bug in autotools and bash, rather than by convenience. The crlf snapshot thing is motivated by ease of use. >> If we don't provide tarballs and then expect users to go through a conversion, Are tarballs or integration a higher priority to you? Because it sounds like Peter is responsible for both. I don't know how many people have a similar-enough setup to Peter to be able to help with snapshot script-writing, and my bash skills are not all there. >> The only files that might need conversion are the .c/.h, because we >> expect people to use them in editors that won't be able to handle a >> specific line terminator if we enforce one. As discussed elsewhere with Segher, I'm not aware of a modern utility that fails to handle CONSISTENT line endings, except perhaps a problem with regular expression matching. Even "more", which nobody uses anymore, seems to work fine for me, as I pointed out. Mixed line endings within a file, and comparing a LF file with one that uses CRLF may be a problem for a lot of programs. >> Even as they are text, if we know, as we do, the line ending format that >> we want for these files, git has no business whatsoever to convert them. >> None. If it can do it right, and it makes things more compatible in terms of working around apparent git problems, why not? >> Now, and this is also the important part that you may have missed, my >> tests at the time (supertest) showed that even with eol=lf, one could >> get CRLF on the files that should be LF (.sh), and this is why I believe >> that -crlf is the only approach that will work. We may have to re-run that test, though. Perhaps push a temporary branch that has those files moved to a different directory. Switch to that branch, then switch back to supertest and see if it works. That's my theory as to what happened with the msvc files, given that libusb.dsw is in a different directory in your master than in pbr288 and supertest. >> confident in git's line conversion, but, from experience, I'm not, and >> as far as I know, Michael also has found reasons not to be either. Well, I'm confident that IF it decides to do the conversion, it does it right. git's lazy evaluation of .gitattributes worries me (assuming that's what the problem is, and that's just my theory...the raw evidence is farther back...I'd love to hear an alternative theory). >> And as Michael pointed out, he didn't have an issue with -crlf on .sh. But I also don't necessarily have a problem with eol=lf. We need more testing. See what I suggested about a branch above. >> ask ALL our users to upgrade their git to a version that >> is less than 6 months old... That commit I identified is just under 7 months old, so yes. Regards, Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-07 13:29:03
|
On 2010.12.07 12:39, Michael Plante wrote: > Pete Batard wrote: >>> if they use MSYSgit whose defaults are >>> autocrlf=true, safecrlf=false, as advocated by Peter > > Two different things. Yes, those are defaults, no they are not advocated by > Peter. Peter said to use safecrlf=true on Windows (at least to you, Orin, > and me). The "as advocated by Peter" was related to eol=lf, not the rest. I should have been clearer here. > And this could be the snapshot solution. LF in tarballs, CRLF in zipfiles. > Slightly more work writing the script, but not too bad? What do you mean? MS projects being LF in tarballs? > The eol=lf for .sh/.ac is a completely separate issue, and one that I think > only Segher and Xiaofan think doesn't need to be solved. Pete seems to > prefer -text, and everyone else, eol=lf. I only prefer -text because I found that eol=lf didn't work when I tried it in July. Had I found that eol=lf worked, I would have no objection with this solution, provided the expectation is that it will result in LF files, no matter the options set in git. > Are tarballs or integration a higher priority to you? Because it sounds > like Peter is responsible for both. I don't know how many people have a > similar-enough setup to Peter to be able to help with snapshot > script-writing, and my bash skills are not all there. Well, personally, there's so much left open with regards to integration that I would see it a priority compared to snapshots. We won't have much of any snapshots to provide if we still don't know what should go in them... >>> Now, and this is also the important part that you may have missed, my >>> tests at the time (supertest) showed that even with eol=lf, one could >>> get CRLF on the files that should be LF (.sh), and this is why I believe >>> that -crlf is the only approach that will work. > > We may have to re-run that test, though. Perhaps push a temporary branch > that has those files moved to a different directory. Switch to that branch, > then switch back to supertest and see if it works. That's my theory as to > what happened with the msvc files, given that libusb.dsw is in a different > directory in your master than in pbr288 and supertest. Yeah. I can't say that I am confident that I didn't screw up these tests somehow. But my line of thinking is that if I managed to screw up eol=lf conversion, even if it was due to very specific conditions, then someone else can do so. >>> And as Michael pointed out, he didn't have an issue with -crlf on .sh. > > But I also don't necessarily have a problem with eol=lf. We need more > testing. See what I suggested about a branch above. I'll try that. Hopefully later today. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-07 23:51:18
|
Pete Batard wrote: >> On 2010.12.07 12:39, Michael Plante wrote: >> > And this could be the snapshot solution. LF in tarballs, CRLF in zipfiles. >> > Slightly more work writing the script, but not too bad? >> >> What do you mean? MS projects being LF in tarballs? No, source and docs LF in tarballs, CRLF in zipfiles. Everything else is, I think, agreed on: sh/ac/am always LF in both, ds?/vcproj/sln always CRLF in both. >> Yeah. I can't say that I am confident that I didn't screw up these tests >> somehow. But my line of thinking is that if I managed to screw up eol=lf >> conversion, even if it was due to very specific conditions, then someone >> else can do so. Yes, but I have no reason to be confident that -text works, either. >> Just tested grep, more (less), vim, and a few other command line tools >> in cygwin and MinGW, and at least for the versions I have, they are CRLF >> aware. Yes, the grep test Segher proposed does work in the version of grep I have in Windows. It just doesn't work in Linux. I hadn't thought to test that. >> Provided [...] >> the results I experienced in July when using "eol=lf" were just a fluke. Now I'm curious whether you were using a version of git that was at least as new as May 19th, plus however long it takes msys to package it. Segher Boessenkool wrote: >> >> What you are missing is that all people who need the build files >> >> with LF line endings, need *all* text files with LF line endings. >> > >> > Which means that people using Tgit and MSVC (CRLF) are supposed to >> > retrieve all their files including the autotool ones with CRLF, and >> > cannot switch environments without a new pull (provided they set their >> > options right). >> >> Without a new checkout, yes. A separate tree would certainly help in >> keeping the user sane. Ah, Pete, tell me if this would help: 1. put two trees on your Linux box, one with autocrlf=false locally, and one with it true. 2. Set the one with autocrlf=false to pull from the one with it true. 3. Copy files between the one with autocrlf=true and Windows. Would that help you out? I think that *avoids* the need to have filesystems visible one way or the other (SMB, NFS, etc), unlike the other option I suggested. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-08 00:21:53
|
On 2010.12.07 23:44, Michael Plante wrote: > Ah, Pete, tell me if this would help: > > 1. put two trees on your Linux box, one with autocrlf=false locally, and one > with it true. > > 2. Set the one with autocrlf=false to pull from the one with it true. > > 3. Copy files between the one with autocrlf=true and Windows. > > Would that help you out? I think that *avoids* the need to have filesystems > visible one way or the other (SMB, NFS, etc), unlike the other option I > suggested. I appreciate the suggestion, but I still need to - commit changes I want to test to a branch that's different than my master (so work on a new master-dev branch set to a private remote I set on my Linux machine - don't really want my testing to be public) - push (Windows) - pull (Linux) before I can test vs copy relevant file and test. Plus I'd also have the extra steps of picking/merging the commit(s) from master-dev into master and switch to master before I can finally push to the public remote. If I want to test a change that's non Windows specific properly, I usually need to try to test 5 environments (if not 6), listed below in order I would usually check them: - MSVC - DDK (superfast - never a bother to test) - MinGW (64) - Linux - cygwin - MinGW (32 - This is the one I usually skip) If it's major, I'll also go as far as testing OSX (ha*cough*tosh). As you can guess, this is quite time consuming (I wish running autotools cleanly in MinGW and especially cygwin was as fast as it is on Linux or OS-X - I haven't measured explicitly, but for the same hardware conf, I'd say it's probably 10 times as slow, no kidding). If I see a possibility of shaving time off, and expect libusb users (who might be wanting to run similar tests if they're developing multi-platform), to benefit from it, without penalizing others, I will obviously try to shave time off, even if deemed not sane, especially when "sane" means I am supposed to pull for each environment on Windows and use a separate repo. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-08 00:31:22
|
Pete Batard wrote: >> On 2010.12.07 23:44, Michael Plante wrote: >> > Ah, Pete, tell me if this would help: >> > >> > 1. put two trees on your Linux box, one with autocrlf=false locally, and one >> > with it true. >> > >> > 2. Set the one with autocrlf=false to pull from the one with it true. >> > >> > 3. Copy files between the one with autocrlf=true and Windows. >> > >> > Would that help you out? I think that *avoids* the need to have filesystems >> > visible one way or the other (SMB, NFS, etc), unlike the other option I >> > suggested. >> >> I appreciate the suggestion, but I still need to >> - commit changes I want to test to a branch that's different than my >> master (so work on a new master-dev branch set to a private remote I set >> on my Linux machine - don't really want my testing to be public) No, this is different from the other suggestion I offered in that regard. You still work on your master branch in Windows, but you don't push from Windows until you've finished testing. Then you can reset --hard on Windows with no consequences. >> - push (Windows) No. >> - pull (Linux) before I can test Yes. Between the two Linux repositories. Not to the network. Therefore, no "oops!" commits, as you put it, yet you still work on whichever branch you were on. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-08 00:47:16
|
On 2010.12.08 00:31, Michael Plante wrote: >>> - pull (Linux) before I can test > > Yes. Between the two Linux repositories. Not to the network. Therefore, > no "oops!" commits, as you put it, yet you still work on whichever branch > you were on. So if I understand properly: - pick up the file I want to test from Windows and SMB it over to the autocrlf=true repo - commit that file and push - cd to other repo and pull Still not as fast as earlier, but not as bad as previous option... Still need to consider the option of just unsing a script alias that simply do2unix-ify the .ac/.am/.sh I copy over, as, as long as I'm not using non CRLF aware tools to read CRLF files on Linux, it's still faster. That's probably what I'll end up doing for if I don't have a choice. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-08 00:52:39
|
Pete Batard wrote: >> - pick up the file I want to test from Windows and SMB it over to the >> autocrlf=true repo or SCP. My point was avoiding SMB&NFS. There was an "avoids" in what I said, not a "requires". >> - commit that file and push except no push required. >> - cd to other repo and pull Yes. >> Still not as fast as earlier, but not as bad as previous option... Still >> need to consider the option of just unsing a script alias that simply >> do2unix-ify the .ac/.am/.sh I copy over, as, as long as I'm not using >> non CRLF aware tools to read CRLF files on Linux, it's still faster. >> That's probably what I'll end up doing for if I don't have a choice. Yes. And keep in mind that I originally questioned you about this procedure not because you were copying files, but because it sounded like you were also copying the .git/ directory, which contains internal data. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-08 00:54:51
|
On 2010.12.08 00:52, Michael Plante wrote: > because it sounded like you were > also copying the .git/ directory, which contains internal data. If I gave that impression, then that's my mistake. The repo I use for testing on Linux is pulled from the public remote (and I reset --hard after I'm done testing). There's no copying of .git occurring. /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-07 16:58:26
|
>>> > People will need exactly those same settings for any other open >>> source >>> > project hosted in git, >>> >>> It's not because other people do one thing that we should follow suit, >>> when we can fix a potential issue that they don't seem to either be >>> aware of, or be willing to fix. > > I don't necessarily agree/disagree with Segher here on the whole. > However, > this whole "let's do what everyone else does" mindset is slightly > annoying. I recommend doing the same as all other projects do, since that is _easier for all users_. > Particularly since that eol attribute was only introduced in May, it > seems. > Maybe no one else has bothered to follow up on new features (having had > this > discussion when different features were available), or maybe no one else > cares enough, or maybe no one else has the same priorities, or maybe they > were using a different VCS and that affects things in some way. Or maybe no one else considers this a problem? >>> > Also, users who do not know this stuff are much more likely to use >>> > tarballs / zipfiles anyway, as has been pointed out to you a lot of >>> > times already. > > And this could be the snapshot solution. LF in tarballs, CRLF in > zipfiles. > Slightly more work writing the script, but not too bad? If we automate making release tarballs/zipfiles (and we should), it is trivial to use the same thing for snapshots as well > As discussed elsewhere with Segher, I'm not aware of a modern utility that > fails to handle CONSISTENT line endings, As I said there, and I'll say again: *ANY* unix program that doesn't specifically handle CRLF, will not handle CRLF. That is, most of them. The consequences of that are benign in many cases. They are not in other cases. That's the "autotools bug" as you guys call it. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-07 23:42:37
|
Segher Boessenkool wrote: >> If we automate making release tarballs/zipfiles (and we should), it is >> trivial to use the same thing for snapshots as well I have not been making a distinction between tarballs and snapshots. Is there one? Michael |
|
From: Segher B. <se...@ke...> - 2010-12-07 23:58:26
|
>>> If we automate making release tarballs/zipfiles (and we should), it is >>> trivial to use the same thing for snapshots as well > > I have not been making a distinction between tarballs and snapshots. Is > there one? _Release_ tarballs, which we should have no matter what. When you can generate those automatically, it should be trivial to make nightly (or whatever) snapshots as well. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-08 00:03:27
|
Segher Boessenkool wrote: >> _Release_ tarballs, which we should have no matter what. When you can >> generate those automatically, it should be trivial to make nightly (or >> whatever) snapshots as well. Well, that involves figuring out the right git hooks to automate it (meaning knowing what a git server looks like), and also thinking through any security issues involved in allowing semi-trusted people to cause the server to publish files in tarball format. The latter may turn out to be a non-issue, but I would certainly worry about it if it were my server. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-08 02:10:35
|
> Segher Boessenkool wrote: >>> _Release_ tarballs, which we should have no matter what. When you can >>> generate those automatically, it should be trivial to make nightly (or >>> whatever) snapshots as well. > > Well, that involves figuring out the right git hooks to automate it Git hooks? Oh, you want snapshots from the git tree? We have those already, see the "zip" etc. links at the right on http://git.libusb.org/?p=libusb.git;a=summary (use unzip -a or -aa if you want CRLF -- or whatever your zip program wants if it's not infozip). There are tarballs as well. What I meant are snapshots like the releases, which do not require you to have (the correct version of) autotools installed, etc. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-08 02:15:21
|
Segher Boessenkool wrote: >> Git hooks? Oh, you want snapshots from the git tree? We have those >> already, see the "zip" etc. links at the right on >> http://git.libusb.org/?p=libusb.git;a=summary >> (use unzip -a or -aa if you want CRLF -- or whatever your zip program >> wants if it's not infozip). There are tarballs as well. With modifications in the tarball, unless you have changed your mind and now support listing nearly every file in .gitattributes. >> [...] do not require you >> to have (the correct version of) autotools installed, etc. That too, but per commit. Michael |
×
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