Menu
▾
▴
libusb-devel
|
From: Michael P. <mic...@gm...> - 2010-12-05 18:17:38
|
Pete Batard wrote: >> 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 suspected. But then you said precisely that to me. Why is your case different from (better than) mine, particularly when you're not using the recommended safecrlf setting? >> and keeps a mix of branches that have >> conflicting settings NOT by my choice. You made that choice for me. >> and then complain that the *EXPERIMENTAL* branch >> is not stable. Just to be clear, the "EXPERIMENTAL" branch is pbatard/master, right? If so, then daniel/master will also contain "experimental" code when (if) it's integrated, right? >> 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. Until Peter catches up, it's just you and me actually pushing Windows changes to git. (And primarily you...I don't mean to shortchange you here.) To extrapolate from a 50/50 situation seems a bit premature. Also don't misunderstand this: I understand that Graeme, Orin, and others have contributed significant amounts of code, but the relevant distinction to the argument is that it wasn't tied to maintaining a long-standing git repo. So it's 50/50 so far. We both have autocrlf turned on, something warned about in the kerneltrap thread you cited. >> 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. And to clarify further, the problem lies not with MSVC itself, but with the way they're treated in git. While I haven't tried loading them into MSVC with LF endings, I wouldn't be surprised if that works. Nevertheless, I prefer CRLF for them. But then the same issue would arise for all the other text files I listed, but that have not yet had .gitattributes lines added in libusb-pbatard.git. >> because they are using >> branches that have different settings. Not exactly. I have one set of settings. My git branch that tracks yours has a different set, as of relatively recently, and not by my choice. I.e., it is your branch that changed. >> 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), If you're right, then this problem will only persist until integration of the relevant files is complete. When will that be? It sounds like things will be a pain until then... >> => only ONE user affected. And only ONE unaffected. I suppose the third test case in this entire exercise will be to see if Peter is affected. >> "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" Well, there is precedent... I find it curious that we're telling git to keep hands off, rather than just telling it what the line endings SHOULD be. Do you think doing it that way would fix things? >> But sure, as always, our time is a lot more >> valuable than the time that's going to be wasted by ALL those guys. How ironic of you to say that here. .... I guess I'll close with one other option: turn off all such options in .gitattributes related to CRLF files and enable autocrlf/safecrlf, but ensure that Peter will unix2dos all files of interest in the snapshots. Keep the .gitattributes related to LF files. Would that work? Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 20:16:26
Attachments:
config
|
On 2010.12.05 18:17, Michael Plante wrote: > You suspected. But then you said precisely that to me. Why is your case different from (better than) mine, particularly when you're not using the recommended safecrlf setting? As you pointed out earlier, I applied the safecrl settings advised by Peter when I started my branch (I remember getting my fingers slapped on this list for not using it). It's only lately that Peter has been advocating different settings... And from what I recall, I had the same issue on a different machine where I just installed TGits/MSys-git (but I haven't tested a full reinstall since). I've seen the issue *twice* when using defaults Tgit settings, therefore I feel I have grounds to extrapolate... How many more machines do I have to test with to convince people that this is anything but a matter of "personal preferences". >>> and keeps a mix of branches that have >>> conflicting settings > > NOT by my choice. You made that choice for me. Yes, because, after I found a way to enforce LF on .sh, I thought if we want to be on the safe side, we should enforce CRLF on MS project files (because I don't see why they should EVER be converted to LF, even for storage), to avoid potential future issues. Sounds like the safe approach to me, even if it's not safe for your existing branches. >>> and then complain that the *EXPERIMENTAL* branch >>> is not stable. > > Just to be clear, the "EXPERIMENTAL" branch is pbatard/master, right? If so, then daniel/master will also contain "experimental" code when (if) it's integrated, right? There are 2 shades of experimental here, so please allow me to clarify. - Shade 1: experimental as: "we will potentially heavily modify and break things that used to work, so that we get them right, and we won't think twice about it - you have been warned" - Shade 2: experimental as: "well, we think we got things right, but this is still new code, therefore, if we have to, we might have to reluctantly revert/break things. But we will do everything we can to avoid that." My branch is full shade1 for anything that has not yet been integrated into official, and official would be shade2, as the Windows backend is marked as experimental. As long as files that I use in my branch (.gitattributes, .dsw, .dsp) have not been integrated in official, they're in "shade 1" mode, and I'll do whatever I want with them, especially if I think they can be improved on to avoid the possibility of dealing with a breakage/regression in shade 2. But if you want to go that way, yes, in essence, as long as the Windows backend in official remains experimental (and it should remain so for a few months even after initial Windows backend release, as I advocated many times for already), then if we have to break things there and piss people off in order to improve on our implementation, then so be it. That's what the Linux kernel does when they tag features as experimental, and it sounds like a good approach when what you want are people to test for bugs. If you expect the Windows backend to be stable right off the bat in the official branch, then better start looking for a better developer, cos I'm definitely not that good. As much as I'd like to pretend otherwise, I'm pretty sure we will find bugs that are going to annoy people in the Windows backend and where the fix will break some of their stuff. This actually would have happened if integration had already been completed and we had introduced new_enum. Likewise, I don't see much of a problem introducing new .gitattributes on files in official that we don't want git to convert, even if people complain (as long as they only affect code tagged as experimental). >>> 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. > > Until Peter catches up, it's just you and me actually pushing Windows changes to git. (And primarily you...I don't mean to shortchange you here.) To extrapolate from a 50/50 situation seems a bit premature. Seen it on 2 completely different machines, and I'm not even using safecrlf/autocrlf on the second one (config attached. And as you'll see there, this was a pure read only clone). I think that gives me the right to extrapolate on the fact that all TGit users are likely to be affected, and to reject your 50/50 argument. On that machine, without the .gitattributes fix, .sh, .ac and .am have CRLF endings and will prevent cygwin compilation. And if people for any reason copy their repo to a Linux machine (so as not to have to fetch it again), compilation will also be broken on Makefile.am. The likelihood of people using TGit and running into an issue is much greater than the likelihood of people having a branch that originates from a pre 2010.07.31 commit off libusb-pbatard. > We both have autocrlf turned on, something warned about in the kerneltrap thread you cited. Yes, because someone advised us to do so (but even if you don't have autocrlf the problem seems to exist). > Nevertheless, I prefer CRLF for them. But then the same issue would arise for all the other text files I listed, but that have not yet had .gitattributes lines added in libusb-pbatard.git. Yeah, not sure what we should do here. If anything, I'd prefer have well defined CRLF'd required files before we complete integration... even if that breaks your branches, but the only files that matter to me really are the .sh/.ac/.am because these are the only ones I expect causing major issues to our users. >>> because they are using >>> branches that have different settings. > > Not exactly. I have one set of settings. I'm counting different .gitattributes as settings, because that's what it really is. It's a setting that tells git not to convert line endings (on specific files). >>> => only ONE user affected. > > And only ONE unaffected. On 2 different machines, with different git settings on CRLF conversion and with the expectation that many more will be. > I suppose the third test case in this entire exercise will be to see if Peter is affected. If the git documentation is accurate, I doubt he will (provided we apply .gitattributes before we integrate MS proj, which is how I presented the patches). I really see no logical reason for him to be affected. > Well, there is precedent... I find it curious that we're telling git to keep hands off, rather than just telling it what the line endings SHOULD be. Do you think doing it that way would fix things? But that's very much what I am doing. I'm telling git to keep its hands off of line endings that I have set, so in essence, I am really telling it what the line endings MUST be. For the record, I converted my files when I applied .gitattributes, and this appears very explicitly in commit b5820d34... [1], so I did tell git what the line endings should be, and what's more, CRLF'd MS project files IS what we currently have in the repo, so git DOES very much know what the line endings should be. Of course, if you planned to follow my branch yet skirted around that commit, you are expected to have issues with line endings. > I guess I'll close with one other option: turn off all such options in .gitattributes related to CRLF files and enable autocrlf/safecrlf, but ensure that Peter will unix2dos all files of interest in the snapshots. Keep the .gitattributes related to LF files. Would that work? As I said, I don't have an issue with switching the MS proj files to LF if it is expected MS tools are fine with LF only. I just thought (and still think) CRLF is the safest option, as this is how they are generated (why should we deviate from the format tools generate when storing them in the VCS?), and it doesn't add to the maintainer's workload. Seriously, and this is my main issue here, if we were using a VCS system that didn't attempt to be too smart with regards to line terminations on non code files, we wouldn't have that problem. Our .sh/.ac/.am would be LF always (because that's how I would have cloned them from my original starting point) and MS proj would be CRLF. Tell me again how git really saves us time there, or why we should EVER need CRLF'd .sh/.ac/.am or LF'd MS project files? MS files are destined only for MS environments, where CRLF is the norm, so why do we need to spend time on converting them? Why should we ever want these files to be stored as LF in git, when only MS people are supposed to ever modify them? -crlf solves that problem. And please someone name a platform where shell scripts that are LF only will not run (I'm not saying that there doesn't exist one, but I'd curious to know what that would be if there exists one). Again, -crlf solves that problem. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=commit;h=b5820d34ad6fd3fa719d861daa58e25789ccf232;js=1 |
|
From: Michael P. <mic...@gm...> - 2010-12-05 20:29:58
|
This one needs to be separate from the rest of my replies because of the quoting I'm doing here... Pete Batard wrote: >> As you pointed out earlier, I applied the safecrl settings advised by >> Peter when I started my branch (I remember getting my fingers slapped on >> this list for not using it). Sorry, my recollection (and my search of my email) indicates that you never used safecrlf. On 1/14, you said: >> "Currently I have AutoCrLf set in TortoiseGit. Can't set SafeCrLf as >> there seems to be a bug that prevents any commits when set (at least on >> Windows 7 x64)" On 1/22, Peter privately told me: >> git config core.safecrlf true On 1/28, Peter told Orin: >> Please git config core.autocrlf true; git config core.safecrlf true >> to try to avoid CRLF line endings in patches. On 1/28, you replied: >> Can't set safecrlf with TortoiseGit, as it prevents any pushes when set, >> but I don't think it's much of an issue as I'm only pushing text files. >> The safecrlf is the real only limitation I found with TortoiseGit as all >> the rest is working brilliantly, and seems very stable. On 4/27, you said: >> Also, it >> took me an awful long time to figure out that there was a bug when >> SafeCRLF was selected that prevented me to push. Only on 12/3 has Peter even hinted at a different story, and only after you revealed that you're still not using safecrlf: >> > my git/config for libusb is attached. [mkp note: it shows safecrlf=false] >> >> 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. >> It's only lately that Peter has been >> advocating different settings... That's not 100% clear to me. He does seem to have indicated safecrlf=false may not be harmful. That's about all I've seen. Do you have an email contradicting this? Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 20:46:28
|
On 2010.12.05 20:29, Michael Plante wrote: > This one needs to be separate from the rest of my replies because of the > quoting I'm doing here... > > Pete Batard wrote: >>> As you pointed out earlier, I applied the safecrl settings advised by >>> Peter when I started my branch (I remember getting my fingers slapped on >>> this list for not using it). > > Sorry, my recollection (and my search of my email) indicates that you never > used safecrlf. On 1/14, you said: My bad, I meant autocrlf, sorry about that. I did indeed get my fingers slapped for not using autocrlf, and, as you pointed out, had issues with safecrlf so I didn't use it. For the record, neither are set by default in Tgit (or at least they weren't in the versions I used so far). > Only on 12/3 has Peter even hinted at a different story, and only after you > revealed that you're still not using safecrlf: > >>>> my git/config for libusb is attached. [mkp note: it shows > safecrlf=false] >>> >>> 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. Peter also indicated that autocrlf should be set to input lately: On 2010.12.02 02:13, Peter Stuge wrote: > Maybe we could have helped. I did some testing just now and it seems > that: > > git config core.autocrlf input > > Will make sure that I get files exactly as they are in the repo, > without any CRLF conversion at all. If I want to, I can force CRLF > locally with: > In short, I currently have no idea what settings I should use (probably "input" though I would need to test that it results in files being stored in the right format), and I don't see forcing people to use autocrlf / safecrlf just to get specific files with the right terminators as a better option than making sure that anybody gets the right terminator on the files that matter, regardless of their option. We will get users not applying the settings we expect. We can EASILY address that. The only question is not doing it on the pretence that, for some weird reason, we think that git should store MS project files LF'd in its repo, and that some people might ever want to retrieve the .sh/.ac/.am as CRLF, which really doesn't make any sense. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-05 21:26:17
|
Pete Batard wrote: >> >>> and keeps a mix of branches that have >> >>> conflicting settings >> > >> > NOT by my choice. You made that choice for me. >> >> Yes, because, after I found a way to enforce LF on .sh, I thought if we >> want to be on the safe side, we should enforce CRLF on MS project files >> (because I don't see why they should EVER be converted to LF, even for >> storage), to avoid potential future issues. Sounds like the safe >> approach to me, even if it's not safe for your existing branches. Except that it doesn't seem to work with all settings of autocrlf/safecrlf, a requirement you've previously stipulated. But there are at least two ways to enforce CRLF's, one which stores CRLF's in the repo, and one which doesn't. You chose the former. Additionally, by storing them as LF-only in the repo, no huge-unmanageable-diff exists across any pair of revisions in the repo. In other words, it doesn't break the ability to look through history. So if git can check out a working copy universally as CRLF, and store universally as LF, without any special autocrlf/safecrlf constraints, then it should, particularly if we decide that any files already in libusb.git ought to be CRLF in the working copy. I.e., git should do the conversion, but we should specify how. Hands-off just doesn't seem to work. >> > Until Peter catches up, it's just you and me actually pushing Windows >> > changes to git. (And primarily you...I don't mean to shortchange you here.) >> > To extrapolate from a 50/50 situation seems a bit premature. >> >> Seen it Seen what? MSVC not handling LF's properly? Otherwise, it doesn't sound like you've seen any problems that I would disagree with. My argument relates to the CRLF files. So I don't think you've seen anything; you stated the msvc files' settings were a preventative measure. Arguably it's 100/0, not 50/50; my bad. Again, I have no beef with what you've done with the .sh/.ac/.am stuff (though Peter does), which is presumably what you've "seen". >> on 2 completely different machines, and I'm not even using >> safecrlf/autocrlf on the second one (config attached. And as you'll see >> there, this was a pure read only clone). Attaching the config is not good enough, because there are at least three locations that affect your git config. You really should just post "git config -l", which pulls them all in and shows the "effective" settings. >> And if people for any reason copy their repo >> to a Linux machine (so as not to have to fetch it again), compilation Heh, I find it easier to move it between Linux and Windows BY fetching. In any case, one might want to exercise caution copying the repo, unless you're sure there's any guarantee that the structure under .git/ will remain the same cross-OS. Do you know if "internal" data is consistent across architectures and OSes? Maybe I'm just overly paranoid about copying .*/ directories from some bad experience I've had with svn (.svn/), but svn has probably had more Windows testing than git, so I'll remain suspicious for now. >> Yes, because someone advised us to do so (but even if you don't have >> autocrlf the problem seems to exist). Interesting. You're right. But that still fits with my theory that I sent out to Segher (CC list) an hour or so ago. >> Yeah, not sure what we should do here. If anything, I'd prefer have well >> defined CRLF'd required files before we complete integration... even if To nitpick, I don't think there are any CRLF-required files, so much as CRLF-preferred files. That said, I haven't tested the .ds? files to see if this is true. >> >>> because they are using >> >>> branches that have different settings. >> > >> > Not exactly. I have one set of settings. >> > [context restored!] My git branch that tracks yours has a different set >> > , as of relatively recently, and not by my choice. >> >> I'm counting different .gitattributes as settings, because that's what >> it really is. It's a setting that tells git not to convert line endings >> (on specific files). Yes. We agree on this. I fail to see how this negates my argument. Actually, given your config shows that you're tracking libusb-mplante.git, it could be argued that you ALSO have "branches that have different settings". Do you see what I'm getting at? You're claiming it's my fault for having branches that have different settings. >> If the git documentation is accurate, I doubt he will (provided we apply >> .gitattributes before we integrate MS proj, which is how I presented the >> patches). I really see no logical reason for him to be affected. We'll see. >> I'm telling git to keep its hands off of line endings that I have set, >> so in essence, I am really telling it what the line endings MUST be. No, you're telling it not to touch them. So you could insert MIXED line endings in there right now and git wouldn't touch them. So git has trouble figuring out what to do because it doesn't know what the endings are. Or that's my guess. >> For the record, I converted my files when I applied .gitattributes, and >> this appears very explicitly in commit b5820d34... [1], so I did tell >> git what the line endings should be, and what's more, CRLF'd MS project >> files IS what we currently have in the repo, so git DOES very much know >> what the line endings should be. And I was unable to do this, as I've been pointing out. >> Of course, if you planned to follow my branch yet skirted around that >> commit, you are expected to have issues with line endings. Like I said, once you pushed that commit (following zero discussion), I tried for a few hours to reproduce the change on my side, after which I complained to you privately. Only when we decided we couldn't agree was I forced to "skirt" that commit. >> > I guess I'll close with one other option: turn off all such options >> > in .gitattributes related to CRLF files and enable autocrlf/safecrlf, >> > but ensure that Peter will unix2dos all files of interest in the >> > snapshots. Keep the .gitattributes related to LF files. Would that work? >> >> As I said, I don't have an issue with switching the MS proj files to LF >> if it is expected MS tools are fine with LF only. I just thought (and >> still think) CRLF is the safest option, as this is how they are >> generated (why should we deviate from the format tools generate when >> storing them in the VCS?), and it doesn't add to the maintainer's workload. And CRLF is precisely what MSVC would see, due to autocrlf. How is that any less safe? MSVC only sees the working copy. Please re-read what I wrote and consider the effects. >> Why should we ever >> want these files to be stored as LF in git, when only MS people are >> supposed to ever modify them? -crlf solves that problem. Because, afaict, doing otherwise breaks with safecrlf. >> And please someone name a platform where shell scripts that are LF only >> will not run DOS? :) Seriously, though, I noticed you didn't mark the .cmd file as hands-off... >> Another possibility is that git is not smart enough to detect that if a >> .gitattributes is part of a commit, it should create it first and apply >> its settings (and I guess I should have broken my commit there, as I did >> break it up for official), so even as the patch operation should have >> converted the files in your repo, it didn't, and you would have had to >> unix2dos them right after. That makes no sense because unix2dos operates on the working copy, which is ALREADY crlf. The problem is that git would not put them into the repo with CRLF. And maybe it shouldn't. In another email, same thread, Pete wrote: >> In short, I currently have no idea what settings I should use (probably I'm not sure either, and I think it's a waste of my time to speculatively change now until Peter weighs in. >> "input" though I would need to test that it results in files being >> stored in the right format), and I don't see forcing people to use >> autocrlf / safecrlf just to get specific files with the right >> terminators as a better option than making sure that anybody gets the >> right terminator on the files that matter, regardless of their option. Yes, but I suspect you're essentially forcing me to set safecrlf=false, rather than what I have now. Did you have a chance to try the patch I posted? I'd be interested to know if it works with both possible settings of safecrlf. Regards, Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 22:29:19
|
On 2010.12.05 21:25, Michael Plante wrote: > Pete Batard wrote: >>>>>> and keeps a mix of branches that have >>>>>> conflicting settings >>>> >>>> NOT by my choice. You made that choice for me. >>> >>> Yes, because, after I found a way to enforce LF on .sh, I thought if we >>> want to be on the safe side, we should enforce CRLF on MS project files >>> (because I don't see why they should EVER be converted to LF, even for >>> storage), to avoid potential future issues. Sounds like the safe >>> approach to me, even if it's not safe for your existing branches. > > Except that it doesn't seem to work with all settings of autocrlf/safecrlf, > a requirement you've previously stipulated. Doesn't it? I'm expecting it to work always, since my understanding is that -crlf tells git to bypass any autocrlf/safecrlf settings. I fully expect it to work regradless of what autocrlf/safecrlf one has, which is a big advantage. > But there are at least two ways > to enforce CRLF's, one which stores CRLF's in the repo, and one which > doesn't. You chose the former. Yup, because I don't see why git should ever need to store files that don't need to be de-CRLF'd as de-CRLF'd. If it's only to prevent mixing at the expend of getting users with autocrlf/safecrlf settings that won't get CRLF on clone, then the choice is pretty obvious. > Additionally, by storing them as LF-only in the repo, no > huge-unmanageable-diff exists across any pair of revisions in the repo. Poor argument. Huge diff will not happen on official precisely because we know the .gitattrributes we want and we'll be committing CRLF'd files in the first place. As to unmanageable diff on an experimental repo that's under my full control, I do hope I still have the freedom to commit whatever I want there, as long as the patches I submit to official are satisfactory. > In > other words, it doesn't break the ability to look through history. (...) That's not what I experience in my branch (I'm much more annoyed by the underscoring move to msvc/ that actually broke history [1]). And again, there won't be any huge diff in official if we commit CRLF initially, as is the plan. > So I don't think you've seen anything; you > stated the msvc files' settings were a preventative measure. Arguably it's > 100/0, not 50/50; my bad. Again, I have no beef with what you've done with > the .sh/.ac/.am stuff (though Peter does), which is presumably what you've > "seen". I have no problem with 100/0 in your favour for MSVC files, since, again, I don't see how anybody else should logically be affected. 100% of a single user having an issue is fine with me, which is what I logically expect with the MSVC issue. >>> And if people for any reason copy their repo >>> to a Linux machine (so as not to have to fetch it again), compilation > > Heh, I find it easier to move it between Linux and Windows BY fetching. Well, sometimes I want to ensure that something I plan to commit to core isn't going to break Linux. Now if I commit to my repo and it turns out that it does break Linux, I have a very public change that I need to fix. If I copy files or directories (simpler when there's more than one file) I can catch it early and avoid public humiliation ;) Does this scenario make sense to you? It does occur on regular basis for me. > one might want to exercise caution copying the repo, Agreed. But if you exercise caution on everything, you're not being very productive. > Actually, given your config shows that you're tracking libusb-mplante.git, > it could be argued that you ALSO have "branches that have different > settings". Do you see what I'm getting at? You're claiming it's my fault > for having branches that have different settings. If you branch off libusb-pbatard and don't follow what I do, up to .gitattributes and CRLF'd files in my repo, then it's your problem. It might not be your fault if the issue was introduced by git to CRLF'ing files in your repo as it should have when you tried to apply the patch, but if you don't follow my .gitattributes, when I'm supposed to be the authority for Windows commits, and your problem is linked to .gitattributes, the responsibility for it is yours. > No, you're telling it not to touch them. So you could insert MIXED line > endings in there right now and git wouldn't touch them. I already debated that point elsewhere. I don't see it as a problem if the alternative is to shift issues on our git users as a result, so that a very limited set of developers avoid them. >>> Of course, if you planned to follow my branch yet skirted around that >>> commit, you are expected to have issues with line endings. > > Like I said, once you pushed that commit (following zero discussion), I > tried for a few hours to reproduce the change on my side, after which I > complained to you privately. Only when we decided we couldn't agree was I > forced to "skirt" that commit. OK, I'll take the blame for not pushing it too hard on my side, and I'll tell you why: the MS proj are simple text files. I fail to see how you couldn't have cloned my repo from scratch and then reapplied your changes on top of it, expect the MS projs, and then copy/pasted into the MS projs (and presumably only the MSVC6 ones, since that's what you are using). Heck, if you have a public branch that you want to see fixed, I'll cone it and do that for you, as I don't expect it to take that long to fix. > And CRLF is precisely what MSVC would see, due to autocrlf. Except is someone new to git doesn't have autocrlf set as it should. Let's say we're finally working on hotplug, and don't have a snapshot yet. I'm pretty sure Windows users might be interested in retreiving the repo. Well, if they use TGit, it's game over on having CRLF in the project files. Granted, they'll probably be fine with LF only, but this is not how we would like their project files to be. >>> Why should we ever >>> want these files to be stored as LF in git, when only MS people are >>> supposed to ever modify them? -crlf solves that problem. > > Because, afaict, doing otherwise breaks with safecrlf. Not when you understand that if you have both .gitattributes and converted files in your repo, it doesn't. It only broke on your system because, as you admitted, you weren't able to apply all the required -crlf changes, which I'm pretty sure I can fix if I can get access to the branch you want to see fixed. >>> And please someone name a platform where shell scripts that are LF only >>> will not run > > DOS? :) Seriously, though, I noticed you didn't mark the .cmd file as > hands-off... Was talking about .sh, though you're right, technically cmd are shell scripts. But the only files that have been causing issues were .sh. As to the cmd DDK files, not sure yet what to do with them yet. I'm expecting them to work as LF (along with the "_source" files), but I'll test that before resubmitting the .gitattribute. >>> Another possibility is that git is not smart enough to detect that if a >>> .gitattributes is part of a commit, it should create it first and apply >>> its settings (and I guess I should have broken my commit there, as I did >>> break it up for official), so even as the patch operation should have >>> converted the files in your repo, it didn't, and you would have had to >>> unix2dos them right after. > > That makes no sense because unix2dos operates on the working copy, which is > ALREADY crlf. The problem is that git would not put them into the repo with > CRLF. I think if you have -crlf, and the files are LF'd in the repo, git will be smart enough to spot the differences. There's probably no need for unix2dos but you do need to recommit the files. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=history;f=_libusb_2008.sln;h=c1b44c7a7b0ce5c880a732995e0b3df621132408;hb=7093b1f58526700043a85f818eb4f38ac3cc87a0;js=1 |
|
From: Pete B. <pb...@gm...> - 2010-12-05 22:38:43
|
On 2010.12.05 22:29, Pete Batard wrote: > I fail to see how you > couldn't have cloned my repo from scratch and then reapplied your > changes on top of it, expect the MS projs, and then copy/pasted into the > MS projs (and presumably only the MSVC6 ones, since that's what you are > using). Heck, if you have a public branch that you want to see fixed, > I'll clone it and do that for you, as I don't expect it to take that long > to fix. OK, presumably, you'll answer that you want to keep your history, in which case you can still delete the *.ds_ from git altogether, apply .gitattribute, copy/paste/fix them, and add them back. If they are CRLF when you add them and you have -crlf, I do expect it to work. Have you tried something similar? Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-05 23:16:29
|
Pete Batard wrote: >> > Except that it doesn't seem to work with all settings of autocrlf/safecrlf, >> > a requirement you've previously stipulated. >> >> Doesn't it? I'm expecting it to work always, since my understanding is >> that -crlf tells git to bypass any autocrlf/safecrlf settings. >> >> I fully expect it to work regradless of what autocrlf/safecrlf one has, >> which is a big advantage. I'm no longer sure, as of an hour or so ago. The problem was that I was unable to fix my own repo. But now I'm not sure if safecrlf is the problem. I still have reason to believe it's *A* problem, but it may not be THE problem. >> Yup, because I don't see why git should ever need to store files that >> don't need to be de-CRLF'd as de-CRLF'd. If it's only to prevent mixing >> at the expend of getting users with autocrlf/safecrlf settings that >> won't get CRLF on clone, then the choice is pretty obvious. It should be independent of autocrlf/safecrlf, so I'm not sure what you mean by "expense". It should be transparent to users. >> > Additionally, by storing them as LF-only in the repo, no >> > huge-unmanageable-diff exists across any pair of revisions in the repo. >> >> Poor argument. Huge diff will not happen on official precisely because >> we know the .gitattrributes we want and we'll be committing CRLF'd files >> in the first place. As to unmanageable diff on an experimental repo >> that's under my full control, I do hope I still have the freedom to >> commit whatever I want there, as long as the patches I submit to >> official are satisfactory. But recall that I wanted the same done to the source files, which already are in official. A huge diff is a non-starter there. This rules out -crlf for source files, but doesn't rule out eol=crlf. >> That's not what I experience in my branch (I'm much more annoyed by the >> underscoring move to msvc/ that actually broke history [1]). And again, >> there won't be any huge diff in official if we commit CRLF initially, as >> is the plan. Hrm, I'm not sure... I'll have to come back to this. >> >>> And if people for any reason copy their repo >> >>> to a Linux machine (so as not to have to fetch it again), compilation >> > >> > Heh, I find it easier to move it between Linux and Windows BY fetching. >> >> Well, sometimes I want to ensure that something I plan to commit to core >> isn't going to break Linux. Now if I commit to my repo and it turns out >> that it does break Linux, I have a very public change that I need to >> fix. If I copy files or directories (simpler when there's more than one >> file) I can catch it early and avoid public humiliation ;) >> >> Does this scenario make sense to you? It does occur on regular basis for me. No, because you should just copy the working copy, not the repo. But yes, I understand why you and Daniel don't usually have the fetch option, while Peter and I do. >> If you branch off libusb-pbatard and don't follow what I do, up to I didn't branch off libusb-pbatard. Remember windows_merge2? The common ancestor lies in Daniel's tree, not yours. I could just as easily say you didn't follow me (not that you necessarily should follow me). >> but if you don't follow my .gitattributes, when I'm supposed to be the >> authority for Windows commits, and your problem is linked to >> .gitattributes, the responsibility for it is yours. Like I said, I tried to. You make it sound like I just ignored the change. I wanted to follow what you did, but it didn't work for me. >> I already debated that point elsewhere. I don't see it as a problem if >> the alternative is to shift issues on our git users as a result, so that >> a very limited set of developers avoid them. Like I also said elsewhere, the difference between -crlf and eol=crlf is nonexistent to users, at least as-proposed. Completely transparent. >> OK, I'll take the blame for not pushing it too hard on my side, and I'll >> tell you why: the MS proj are simple text files. I fail to see how you >> couldn't have cloned my repo from scratch and then reapplied your >> changes on top of it, expect the MS projs, and then copy/pasted into the >> MS projs (and presumably only the MSVC6 ones, since that's what you are >> using). Heck, if you have a public branch that you want to see fixed, >> I'll cone it and do that for you, as I don't expect it to take that long >> to fix. I'm still not sure that'd work. Sure, I'd have your copy of my public branch, but I'm not sure I could get it back into my repository. I'm telling you I was running into WEIRD problems trying to simply copy files out of your repository into mine. Such as git telling me nothing was changed, or else it refusing to commit changes. The latter was almost certainly a safecrlf problem, but I don't remember the details. >> > And CRLF is precisely what MSVC would see, due to autocrlf. >> >> Except is someone new to git doesn't have autocrlf set as it should. Ah. I was only trying to fix things for the snapshots. I assumed that someone starting out with git will set things up properly. Maybe that was too much to assume. But I think that if that's your only objection, then you may be in the minority on that one. But I'll remain open on this. >> Not when you understand that if you have both .gitattributes and >> converted files in your repo, it doesn't. Which I was unable to do. >> It only broke on your system >> because, as you admitted, you weren't able to apply all the required >> -crlf changes, which I'm pretty sure I can fix if I can get access to >> the branch you want to see fixed. I'm sure you could, but I'm also reasonably certain I would not be able to put that back into my repo. I'll have to try again sometime, but first that other discussion needs to be sorted out (separate email). >> As >> to the cmd DDK files, not sure yet what to do with them yet. I'm >> expecting them to work as LF (along with the "_source" files), but I'll >> test that before resubmitting the .gitattribute. Are those "internal only"? That would raise a slight problem with .gitattributes, which is not. >> I think if you have -crlf, and the files are LF'd in the repo, git will >> be smart enough to spot the differences. There's probably no need for >> unix2dos but you do need to recommit the files. Not probably --> certain. Except that git wouldn't let me. >> OK, presumably, you'll answer that you want to keep your history, in >> which case you can still delete the *.ds_ from git altogether, apply >> .gitattribute, copy/paste/fix them, and add them back. If they are CRLF >> when you add them and you have -crlf, I do expect it to work. Have you >> tried something similar? Probably. I don't remember, but it sounds like something I almost certainly would have tried. Regards, Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-05 19:19:30
|
Pete Batard wrote: >> 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 try the attached patch, together with re-checking-in the .ds?/.vcproj/.sln files. I'm not 100% sure (since git is acting strangely), but it at least seems to work for me. This causes the files to be stored as LF, but checked out as CRLF, if I'm reading the docs correctly. Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-05 19:28:44
|
Michael Plante wrote: >> Pete Batard wrote: >> >> 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 try the attached patch, together with re-checking-in the .ds?/.vcproj/.sln >> files. I'm not 100% sure (since git is acting strangely), but it at least seems >> to work for me. This causes the files to be stored as LF, but checked out as CRLF, >> if I'm reading the docs correctly. And checkout/re-checkin is only a required step if git status doesn't show any of those files "changed". E.g., when I try applying this on Linux, that step goes away and I can just commit the patch as-is, because git automatically offers to convert them. This might save some time. The reason is likely because I do not have autocrlf set in Linux, not because of the fact that it IS Linux vs Windows, per se. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 21:38:05
|
On 2010.12.05 19:19, Michael Plante wrote: > Please try the attached patch, You mean the exact same thing that I already tried in my supertest branch [1] (which was dedicated to solving that issue) and which didn't work? Now, I must admit that my prime concern then was with the .sh rather than the solution files, but considering that I found that even with "*.sh eol=lf" my script files would be altered to CRLF, you'll understand that I have little confidence in eol=crlf. Git doesn't have any business of modifying line terminators on MS project files, regardless of whether a maintainer/libusb developer might edit said files and introduce LFs in the process. And I hear you guys say: "But wouldn't it be better if git autocorrected those to ensure CRLF?" Well, if we knew that the eol option worked always, yes, but considering that my tests at the time showed that the eol setting could be overridden and didn't amount to much at enforcing line terminations, it looks like a lesser choice compared to -crlf. Unlike what is the case for eol, we have no reason to suspect that -crlf might not work, and, as far as I am aware right now, it only introduces issue to people caught at the transition if we either haven't been careful enough to split it between .gitattributes / line ending changes, or if they chose not to apply the necessary line ending changes commit that comes with such a move. Besides, when did protecting against clueless maintainers/libusb developers (NB: I'll count myself in that lot if it turns out we need to split commits on .gitattributes before committing changed line endings) become something we should strive for, while protecting against clueless users (whose only bad move was to clone the git repo) isn't? Regards, /Pete http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=73bba959b695fabbe679b3754917ed919218b55d;js=1 |
|
From: Michael P. <mic...@gm...> - 2010-12-05 22:19:49
|
Pete Batard wrote: >> You mean the exact same thing that I already tried in my supertest >> branch [1] (which was dedicated to solving that issue) and which didn't >> work? You know, that's odd. You're right that it doesn't work if I do so in my existing repo, but supertest does work on a clean checkout. This is really strange, as though git has some memory across branch switches other than what's in the config -- like it's not cleaning up the working copy if it only changes in line endings when you switch branches...this may be a git bug. As an example, if I apply the patch on top of your master now in Linux (with autocrlf/safecrlf unspecified, so false), it does work: $ git clone http://git.libusb.org/libusb-pbatard.git . [...] $ emacs .gitattributes [...changed to eol=crlf...] $ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: .gitattributes # modified: _libusb_2008.sln # modified: _libusb_dll_2008.vcproj # modified: _libusb_static_2008.vcproj # modified: msvc/libusb.dsw # modified: msvc/libusb.sln # modified: msvc/libusb_dll.dsp # modified: msvc/libusb_dll.vcproj # modified: msvc/libusb_static.dsp # modified: msvc/libusb_static.vcproj # modified: msvc/lsusb.dsp # modified: msvc/lsusb.vcproj # modified: msvc/xusb.dsp # modified: msvc/xusb.vcproj # no changes added to commit (use "git add" and/or "git commit -a") $ hexdump -C msvc/libusb.dsw |less [...] 00000030 74 20 56 65 72 73 69 6f 6e 20 36 2e 30 30 0d 0a |t Version 6.00..| ^^ ^^ [...] Weird? git marks it modified, yet the working copy is clearly still CRLF. (Note that I did not do any add/commit ops here.) Check this, though, again on Linux with autocrlf/safecrlf unspecified: $ git clone http://git.libusb.org/libusb-pbatard.git . $ git checkout -b prest pbr288 # pbr288 is the common ancestor $ git checkout -b pbst origin/supertest $ hexdump -C libusb.dsw |less [...shows LF-only...] $ git checkout master $ git checkout pbst $ hexdump -C libusb.dsw |less [...shows CRLF...] Dammit!! Maybe safecrlf isn't the problem; maybe git is actually broken here? Am I correct in assuming the entire working copy should be discarded when you switch branches? Then the question becomes, why does it manage to lose its memory when it switches from master to pbr288 and back, but not when switching to supertest? Maybe because the files were moved to another directory (msvc/ instead of /) which forces it to update the working copy? $ equery list git [ Searching for package 'git' in all categories among: ] * installed packages [I--] [ ] dev-vcs/git-1.7.2.2 (0) >> considering that I found that even >> with "*.sh eol=lf" my script files would be altered to CRLF, you'll >> understand that I have little confidence in eol=crlf. I understand your caution. git has been behaving in a manner I cannot explain, even on Linux! >> And I hear you guys say: "But wouldn't it be better if git autocorrected >> those to ensure CRLF?" Well, if we knew that the eol option worked >> always, yes, but considering that my tests at the time showed that the >> eol setting could be overridden and didn't amount to much at enforcing >> line terminations, it looks like a lesser choice compared to -crlf. And my tests have been just the other way around: -crlf doesn't always work. >> Besides, when did protecting against clueless maintainers/libusb >> developers [...] become something we should strive for, while protecting >> against clueless users (whose only bad move was to clone the git repo) isn't? I see it as protecting both. The problem is trying to find a set of settings where git actually does what the docs seem to say it should... :( Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-05 22:56:41
|
On 2010.12.05 22:19, Michael Plante wrote: > This is really > strange, as though git has some memory across branch switches other than > what's in the config -- like it's not cleaning up the working copy if it > only changes in line endings when you switch branches...this may be a git > bug. Mmm, that could explain the weird results I had on supertest. > As an example, if I apply the patch on top of your master now in Linux > (with autocrlf/safecrlf unspecified, so false), it does work: > > $ git clone http://git.libusb.org/libusb-pbatard.git . OK, if you clone my master, the files should be CRLF in your local git repo > $ emacs .gitattributes > [...changed to eol=crlf...] > > $ git status > # modified: msvc/libusb.dsw > no changes added to commit (use "git add" and/or "git commit -a") > > $ hexdump -C msvc/libusb.dsw |less > 00000030 74 20 56 65 72 73 69 6f 6e 20 36 2e 30 30 0d 0a |t Version > 6.00..| > ^^ ^^ > Weird? git marks it modified, yet the working copy is clearly still CRLF. > (Note that I did not do any add/commit ops here.) Maybe git expects that if you use eol=crlf, the repo should have LF (because CRLF conversion is applied on checkout) But since repo is CRLF we have the following when diffing: local CRLF -> stripped to LF (because eol=crlf) -> compared to CRLF => flagged as modified. Could that explain this behaviour? Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-05 23:06:56
|
OK, since this discussion has been going long enough, let me try to propose a trade off there. As I don't have much of an issue with the MS project files, and it is expected that, even if we have conversion issues, they'll still be fine, I'm willing to revert my .gitattributes options on those to whatever suits you, as long as I can keep -crlf on .sh/.ac/.am (which is the only option that I deem safe enough). Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-05 23:17:51
|
Pete Batard wrote: >> OK, since this discussion has been going long enough, let me try to >> propose a trade off there. >> >> As I don't have much of an issue with the MS project files, and it is >> expected that, even if we have conversion issues, they'll still be fine, >> I'm willing to revert my .gitattributes options on those to whatever >> suits you, as long as I can keep -crlf on .sh/.ac/.am (which is the only >> option that I deem safe enough). That's fine, and I appreciate it, but before you go to that effort, please try to explain this: >> $ git clone http://git.libusb.org/libusb-pbatard.git . >> $ git checkout -b prest pbr288 # pbr288 is the common ancestor >> $ git checkout -b pbst origin/supertest >> $ hexdump -C libusb.dsw |less >> [...shows LF-only...] >> $ git checkout master >> $ git checkout pbst >> $ hexdump -C libusb.dsw |less >> [...shows CRLF...] If it turns out that that isn't how things are supposed to behave, then we have a bigger issue. Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-05 23:22:12
|
Michael Plante wrote: >> >> $ git clone http://git.libusb.org/libusb-pbatard.git . >> >> $ git checkout -b prest pbr288 # pbr288 is the common ancestor >> >> $ git checkout -b pbst origin/supertest >> >> $ hexdump -C libusb.dsw |less >> >> [...shows LF-only...] >> >> $ git checkout master >> >> $ git checkout pbst >> >> $ hexdump -C libusb.dsw |less >> >> [...shows CRLF...] >> >> If it turns out that that isn't how things are supposed to behave, then we have a bigger issue. To clarify, what that essentially says is that "which line endings will I get?" is answered by "depends on which order you switched branches in". Note that that sequence of commands makes NO changes to .gitattributes or the repo. (!) In one case, supertest works, and in another case, it doesn't. ...Depending on which branch I was previously on. Unless I'm just being stupid, that's either a misfeature or a bug. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-06 00:41:22
|
Yay, let's spend our Sunday working the idiosynchrasies of git... On 2010.12.05 23:21, Michael Plante wrote: >>>>> $ git clone http://git.libusb.org/libusb-pbatard.git . (Talking only about the .ds_) OK, now you have -crlf'd .gitattributes and CRLF'd files in the repo. >>>>> $ git checkout -b prest pbr288 # pbr288 is the common ancestor .gitattribute is now gone and repo should have LF'd files. Even if .gitattributes was still valid during the branching back (very doubtful, but hey) -crlf would be applied, so the LF -> CRLF conversion would be reverted => we should have LF'd files in the repo. No the question you also mentioned that your autocrlf/safecrlf are off, so from repo to disk there should be no modification => disk files are LF'd >>>>> $ git checkout -b pbst origin/supertest OK, now we're switching to supertest, which adds -crlf in .gitattributes but does NOT convert the files => still LF in the repo and therefore LF'd on disk. >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows LF-only...] Expected. >>>>> $ git checkout master Back to master. Files are (expected) CRLF in the repo and -crlf in .gitattributes. Files on disk expected to be CRLF. >>>>> $ git checkout pbst Back to supertest. Again, same .gitattributes (for the files we care about). Now, everything I've heard about git says it goes through the branch ancestor internally, which is what's you've explicitly done above, so we should end up with LF'd files as we're supposed to revert master/b5820d34a. >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows CRLF...] >>> >>> If it turns out that that isn't how things are supposed to behave, then > we have a bigger issue. OK then we have a bigger issue, and it looks like a git bug to me. Piece of crap! Even when you do everything you can to logically avoid git to put its nose into your line endings, it finds a way to stab you in the back. Another nail in the coffin of trusting git with any line endings as far as I'm concerned. But my guess is that, if we go with -crlf, since we'd be committing new files in official after any application of .gitattributes, people branching off official will not be affected by this behaviour since there would be no commit in the repo where the files are LF only. As to trying to CRLF'ing the code (or LF'ing it), which is something you mentioned, I don't really see much of an issue with it, as long as the repo stays LF. The only issue I see are LF'd files from the repo that MUST not be CRLF'd ever (.sh/.ac/.am) and external CRLF'd files that the repo has no business to LFize (MS proj and possibly .cmd _source). Our .c/.h are in neither category, so whichever option you and the maintainers want to go with is fine by me. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-06 00:55:32
|
Pete Batard wrote: >> On 2010.12.05 23:21, Michael Plante wrote: >> >>>>> $ git clone http://git.libusb.org/libusb-pbatard.git . >> >> (Talking only about the .ds_) OK, now you have -crlf'd .gitattributes >> and CRLF'd files in the repo. Yes. >> >>>>> $ git checkout -b prest pbr288 # pbr288 is the common ancestor >> >> >>>>> $ git checkout -b pbst origin/supertest >> >> OK, now we're switching to supertest, which adds -crlf in .gitattributes >> but does NOT convert the files => still LF in the repo and therefore >> LF'd on disk. No, supertest has eol=crlf on libusb.dsw. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-06 01:22:26
|
On 2010.12.06 00:55, Michael Plante wrote: > No, supertest has eol=crlf on libusb.dsw. Ah shoot! That's why it's a test branch: -crlf wasn't applied everywhere, and I only remember what I did for .sh (which was my prime concern and the goal of supertest) >>>>> $ git clone http://git.libusb.org/libusb-pbatard.git . -crlf'd .gitattributes and CRLF'd files in the repo. >>>>> $ git checkout -b prest pbr288 # pbr288 is the common ancestor .gitattribute is now gone LF'd files in repo. Disk files expected LF. >>>>> $ git checkout -b pbst origin/supertest eol=crlf in .gitattributes, LF'd files in repo, but commits from 288 to upertest latest not touching line endings and eol=crlf expected to apply on checkout only (why not?) so no conversion(?) >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows LF-only...] Expected... when you know what you want to expect and pull out some explanation out of nowhere as I did above. >>>>> $ git checkout master -crlf in .gitattributes, CRLF in the repo and. Files on disk expected CRLF... unless moving forward with the double -crlf in .gitattributes and LF -> CRLF conversion nullifies the LF -> CRLF because .gitattributes is not yet applied (which could have been your issue as well). Would work in reverse, because .gitattributes -crlf is set before reverting the commit. LF in repo? CRLF in repo? Place your bets. >>>>> $ git checkout pbst Supposed to go back to LF. Unless we were already LF git decides to silently apply the reverse of commit patch on files he has a problem with, in which case we would go through LF -> CRLF in the repo... >>>>> $ hexdump -C libusb.dsw |less >>>>> [...shows CRLF...] ...and we get CRLF here. Do I get a prize for the "most logical explanation clearly pulled out of thin air and not backed by any shred of evidence whastoever" contest? In any case, looks like a bug. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-05 23:16:29
|
Pete Batard wrote: >> On 2010.12.05 22:19, Michael Plante wrote: >> > This is really >> > strange, as though git has some memory across branch switches other than >> > what's in the config -- like it's not cleaning up the working copy if it >> > only changes in line endings when you switch branches...this may be a git >> > bug. >> >> Mmm, that could explain the weird results I had on supertest. I mixed up the discussion. The stuff you snipped as the important stuff, and is related to the above. The stuff you did not snip was just slightly odd, but not a problem. >> > As an example, if I apply the patch on top of your master now in Linux >> > (with autocrlf/safecrlf unspecified, so false), it does work: >> > >> > $ git clone http://git.libusb.org/libusb-pbatard.git . >> >> OK, if you clone my master, the files should be CRLF in your local git repo Yes. >> > $ emacs .gitattributes >> > [...changed to eol=crlf...] >> > >> > $ git status >> > # modified: msvc/libusb.dsw >> > no changes added to commit (use "git add" and/or "git commit -a") >> > >> > $ hexdump -C msvc/libusb.dsw |less >> > 00000030 74 20 56 65 72 73 69 6f 6e 20 36 2e 30 30 0d 0a |t Version >> > 6.00..| >> > ^^ ^^ >> > Weird? git marks it modified, yet the working copy is clearly still CRLF. >> > (Note that I did not do any add/commit ops here.) >> >> Maybe git expects that if you use eol=crlf, the repo should have LF >> (because CRLF conversion is applied on checkout) >> But since repo is CRLF we have the following when diffing: >> >> local CRLF -> stripped to LF (because eol=crlf) -> compared to CRLF >> => flagged as modified. >> >> Could that explain this behaviour? Yeah, and I figured as much, but, like I said, this is NOT a problem. That works fine, no issue. It's the stuff you cut out of my email that I think highlights the problem. I'm repasting here: >> $ git clone http://git.libusb.org/libusb-pbatard.git . >> $ git checkout -b prest pbr288 # pbr288 is the common ancestor >> $ git checkout -b pbst origin/supertest >> $ hexdump -C libusb.dsw |less >> [...shows LF-only...] >> $ git checkout master >> $ git checkout pbst >> $ hexdump -C libusb.dsw |less >> [...shows CRLF...] Can you explain that? Sorry for mixing a problem with a simple non-problem point of interest in the same email. Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-05 23:48:50
|
Michael Plante wrote: >> Can you explain that? Sorry for mixing a problem with a simple >> non-problem point of interest in the same email. I can't reproduce this in Windows, though. Even more frustrating... Michael |
|
From: Michael P. <mic...@gm...> - 2010-12-06 00:37:28
|
Michael Plante wrote: >> Michael Plante wrote: >> >> Can you explain that? Sorry for mixing a problem with a simple >> >> non-problem point of interest in the same email. >> >> I can't reproduce this in Windows, though. Even more frustrating... Well, it's clearly recent. I upgraded from msysgit 1.6.5.1-preview20091022 to 1.7.3.1-preview20101002, and now I *can* reproduce it on Windows. Looking around on the git mailing list indicates that a lot of crlf activity has occurred in the past year. I'll try a couple other versions and see if I can narrow it down further. That said, the behavior in 1.6.5.1, while at least consistent (unlike 1.7.2/1.7.3), was consistently bad. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-06 00:58:07
|
On 2010.12.06 00:36, Michael Plante wrote: >>> I can't reproduce this in Windows, though. Even more frustrating... > > Well, it's clearly recent. I upgraded from msysgit 1.6.5.1-preview20091022 > to 1.7.3.1-preview20101002, and now I *can* reproduce it on Windows. OK. Do you suspect this (potential) bug to be the cause of your 2010.08 issue then? /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-06 01:27:57
|
Pete Batard wrote: >> On 2010.12.06 00:36, Michael Plante wrote: >> >>> I can't reproduce this in Windows, though. Even more frustrating... >> > >> > Well, it's clearly recent. I upgraded from msysgit 1.6.5.1-preview20091022 >> > to 1.7.3.1-preview20101002, and now I *can* reproduce it on Windows. >> >> OK. Do you suspect this (potential) bug to be the cause of your 2010.08 >> issue then? As far as being unable to do what I needed? Possibly. I remember seeing bizarre behavior and doubting my own memory of what had just happened. Funny thing is that 1.6.5.1 spits out LF-only in both situations, whereas 1.7.3.1 behaves like the 1.7.2.2 Linux build. Unless autocrlf is set, in which case 1.6.5.1 spits out CRLF-only. I haven't tested 1.7.3.1 in Windows with autocrlf yet. In short, if this observed behavior is changed to something more sane upstream, then I might have better luck fixing my repo. But, more importantly, I don't think we can go forward with eol=crlf until it's fixed. Regardless, it sounds like both Peter and Segher are bothered by having CRLF in the repo itself (i.e., the \r's that show up on gitweb for your repo), unless I'm misunderstanding them. I'm not sure how to proceed now. Options I see: 1) keep your repo as-is, and I spend some time trying to fix mine again with the new version now that I know what to look out for. 1a) I succeed. If it didn't take long, great. If it took a long time and Peter decides he doesn't like what you've done, I've wasted my time twice, once forward, and once reverting. 1b) I fail again. 2) we switch to eol=crlf after git is fixed (assuming it is a bug) and require people to upgrade...possible or not? Forget for a second whether we should reasonably expect everyone to upgrade so quickly, and just pretend we can require people to upgrade...would this cause any problems in libusb.git itself if we wait that long? In essence, taking this option requires taking option 1 or 3 first, and then switching later. Dunno if that's a bad idea. 3) we take your compromise of dropping references to .ds? in .gitattributes and expect people to set autocrlf (which is incidentally set for you in the install wizard for msysgit anyway). Then what? I guess that's the least-bad option, but I'm not sure. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-06 02:13:42
|
On 2010.12.06 01:27, Michael Plante wrote: > 1a) I succeed. If it didn't take long, great. If it took a long time and > Peter decides he doesn't like what you've done, I've wasted my time twice, > once forward, and once reverting. I'm pretty sure Peter will not like -crlf, regardless of whether we prove that your issue will not affect anybody branching off official if we go -crlf on project files, and that this is the safest way to ensure that people who clone/branch-off the official repo don't run into CRLF issues ever. The first thing he did when I asked him to use -crlf on configure.ac was to go with eol=lf instead. > 2) we switch to eol=crlf after git is fixed (assuming it is a bug) and > require people to upgrade...possible or not? I don't like forcing people to use tools that have yet to be released. It's libtool's CJK all over again... > Forget for a second whether we > should reasonably expect everyone to upgrade so quickly, and just pretend we > can require people to upgrade... Huh, OK. :( > would this cause any problems in libusb.git > itself if we wait that long? In essence, taking this option requires taking > option 1 or 3 first, and then switching later. Dunno if that's a bad idea. That would rule out using #1 in the meantime, as we'd then need to get a CRLF -> LF conversion on all the MS project files when we switch back and I expect maintainers not to like such a commit one bit (whereas I see it as acceptable if it's to work around a bug) => we must go with #3. > 3) we take your compromise of dropping references to .ds? in .gitattributes > and expect people to set autocrlf (which is incidentally set for you in the > install wizard for msysgit anyway). Then what? I guess that's the > least-bad option, but I'm not sure. Then we hope that MS environments are fine with non CRLF files (which is what we currently expect, so it's still reasonable), for people who won't have the autocrlf options they're supposed to have. Now of course, if there's ever an issue with ____crlf and we find we want to go -crlf after all, we'll have a conversion commit and then we might find more people experiencing the same issue you had. Or we hope that eol=crlf is fixed when/if that happens, and can't be overruled by config settings... 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