Menu
▾
▴
libusb-devel
|
From: Segher B. <se...@ke...> - 2010-12-08 02:23:05
|
>>> 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. I'm not sure what you're saying here. The tarball will have plain LF for everything (except msvc project files and "binary" stuff like that), since that's how stuff appears in the repo. >>> [...] do not require you >>> to have (the correct version of) autotools installed, etc. > > That too, but per commit. Not sure what you say here either -- you want a "release snapshot" for every commit? Well, every commit on master? Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-08 02:35:34
|
Segher Boessenkool wrote: >> > With modifications in the tarball, unless you have changed your mind and >> > now >> > support listing nearly every file in .gitattributes. >> >> I'm not sure what you're saying here. The tarball will have plain LF >> for everything since that's how stuff appears in the repo. And I was requesting a version be available that is crlf, since tar does not have an autocrlf option last I checked like git does. If the crlf version is zip and the lf version is tgz, that would be very natural. But I hope you're not claiming the only way to put crlf's into the snapshot is to also have them in git. My point is that I was already aware of the link you pointed to on gitweb, and I don't think that satisfies the criteria I've listed, or even one of the ones you listed (autogen). >> (except msvc project files and "binary" stuff like that), Ok, this is a tangent, but the msvc files are "text", unless you're reversing your opinion from what you said earlier: "A 'text' file, from the user's point of view, is anything that is, well, text: documentation files, C source files, build system files, etc." There you go, build system files. >> >>> [...] do not require you >> >>> to have (the correct version of) autotools installed, etc. >> > >> > That too, but per commit. >> >> Not sure what you say here either -- you want a "release snapshot" >> for every commit? Well, every commit on master? Dunno about the "release" part, but yes snapshot. We have discussed in the past having this available per commit on any repo, particularly Pete's. And really I'm just advocating for what I would want if I weren't already involved with libusb (and therefore using my git repo); in a sense, I won't lose a whole lot of sleep if the snapshots do not become available, but I figure there might be users out there who would want something similar. I also have no interest in binaries, but I'm in the minority on that one. Regards, Michael |
|
From: Segher B. <se...@ke...> - 2010-12-08 03:15:27
|
>>> > With modifications in the tarball, unless you have changed your mind > and >>> > now >>> > support listing nearly every file in .gitattributes. >>> >>> I'm not sure what you're saying here. The tarball will have plain LF >>> for everything since that's how stuff appears in the repo. > > And I was requesting a version be available that is crlf, since tar does > not > have an autocrlf option last I checked like git does. If the crlf version > is zip and the lf version is tgz, that would be very natural. Zip can handle text vs. binary files. I'm not so sure gitweb actually handles this though :-( > My point is that I was already aware of the link you > pointed to on gitweb, and I don't think that satisfies the criteria I've > listed, or even one of the ones you listed (autogen). Yes, I've never seen the point in getting source snapshots anyway -- just get the whole repo, git compresses really well. >>> (except msvc project files and "binary" stuff like that), > > Ok, this is a tangent, but the msvc files are "text", unless you're > reversing your opinion from what you said earlier: "A 'text' file, from > the > user's point of view, is anything that is, well, text: documentation > files, > C source files, build system files, etc." There you go, build system > files. Erm, I don't consider any of the MSVC files as "build system". The MSVC maintainers can do whatever they want with them, as long as I can treat them as a black box that just sits as dead weight in some subdir I don't have to look at. I was under the impression Pete wants those files checked in with CRLF and everything, that's all I meant. It seems to me they will work fine also if checked in as LF like everything else, but I don't care, and I don't really even want to know. "Build system" is the autoXXXX stuff, makefiles, that kind of thing. Stuff that humans can edit without GUIs ;-) >>> > That too, but per commit. >>> >>> Not sure what you say here either -- you want a "release snapshot" >>> for every commit? Well, every commit on master? > > Dunno about the "release" part, but yes snapshot. We have discussed in > the > past having this available per commit on any repo, particularly Pete's. Wow. Luckily libusb isn't very big, or that would take a lot of space and time to generate! > And > really I'm just advocating for what I would want if I weren't already > involved with libusb (and therefore using my git repo); in a sense, I > won't > lose a whole lot of sleep if the snapshots do not become available, but I > figure there might be users out there who would want something similar. I don't see it being useful, but if the server admin allows it, why not eh. > I also have no interest in binaries, but I'm in the minority on that one. It's a strange world! /me thinks mswindows devs have arsenic in their DNA. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-08 03:49:18
|
Segher Boessenkool wrote: >> Zip can handle text vs. binary files. Yes. But what I'm saying is that Windows users naturally go for a zip file over a tgz when available. Vice versa in Linux. Right? So no need for them to read instructions indicating which file to get, and they automatically get the right endings. More often than 50/50, anyway. I was not really speaking of the capabilities of either file format, though. >> I was under the impression Pete wants those files >> checked in with CRLF and everything, that's all I meant. It seems to >> me they will work fine also if checked in as LF like everything else, >> but I don't care, and I don't really even want to know. >> >> "Build system" is the autoXXXX stuff, makefiles, that kind of thing. >> Stuff that humans can edit without GUIs ;-) They're still text. You've already said CRLF doesn't mean binary. Are you changing your mind? And I can still edit them, and I even occasionally do, particularly when I don't like what the GUI did. Example: sometimes, the GUI likes to reorder the references to source files for no obvious reason, which makes the diffs a pain, so I'll go back and reorder them manually to make the diffs cleaner, or, alternatively, amend the first commit and rebase so that the new order appears to be what it always was, again cleaning up superfluous diffs. Another example: sometimes it's quicker to search and replace certain things in the text of the project file when the referenced files get moved around than it is to go into the GUI and add/remove every file using a dialog box. The newer versions of MSVC projects are more difficult to understand, introducing undocumented small integers for a lot of things instead of listing what is essentially equivalent to CFLAGS like MSVC6 did. So if all you've seen is the newer stuff, I can understand why you'd think that. But even with xml files, there are ways around the problems you've mentioned such that they can still be treated as text. I have little experience with new versions of MSVC, but Atmel's AVR Studio butchers its project files (in xml) every time you save them, so I run them through a pretty printer right after saving them, but prior to checking for diffs. I'm sure the same thing would work for (new version) MSVC project files. >> Wow. Luckily libusb isn't very big, or that would take a lot of space >> and time to generate! That's a good point. Keep just the last 3 or so per branch, or maybe only the ones that are "git tag"-ged. Although Pete tags a significant fraction of his commits, so there might be some objection to that. Michael |
|
From: Segher B. <se...@ke...> - 2010-12-08 04:55:56
|
>>> Zip can handle text vs. binary files. > > Yes. But what I'm saying is that Windows users naturally go for a zip > file > over a tgz when available. I think so, yes. I'm not sure the zip files gitweb produces will do what you want though, wrt line endings. > Vice versa in Linux. Maybe. But many MacOSX users will grab the zip file. > Right? So no need for > them to read instructions indicating which file to get, and they > automatically get the right endings. More often than 50/50, anyway. More often than 50/50, sure. But if _that_ is your goal, we already have it! I don't think the gitweb-generated tarballs/zipfiles are terribly good for not-so-experienced users. Never mind the line endings -- what about autoconf and other build requirements. Release-like snapshots are a much more robust resource for them. >>> I was under the impression Pete wants those files >>> checked in with CRLF and everything, that's all I meant. It seems to >>> me they will work fine also if checked in as LF like everything else, >>> but I don't care, and I don't really even want to know. >>> >>> "Build system" is the autoXXXX stuff, makefiles, that kind of thing. >>> Stuff that humans can edit without GUIs ;-) > > They're still text. You've already said CRLF doesn't mean binary. Are > you > changing your mind? For the umpteeth time: I don't care about those files. For no environment other than MSVC do they matter at all, as long as they stay out of the way. For anything to do with cross-platform issues, _they don't exist_. As I've also said at least ten times now, if you want to be sure git doesn't mangle line endings on those files, you can check them in as binary files. Which would mean of course that CRs end up in the repo -- all bytes in there do, just like if you checked in a PNG file or whatever. If whoever handles the MSVC project files prefers to do it another way, that's fine with me. >>> Wow. Luckily libusb isn't very big, or that would take a lot of space >>> and time to generate! > > That's a good point. Keep just the last 3 or so per branch, or maybe only > the ones that are "git tag"-ged. I think this whole exercise would become less than useless that way. And I don't think it matters; libusb is very small, machines are huge and fast these days, etc. But I really don't care. > Although Pete tags a significant > fraction > of his commits, so there might be some objection to that. Those tags won't end up in the official repo anyway. Maybe you want Pete to make snapshots off his tree, at least until it gets merged? Segher |
|
From: Peter S. <pe...@st...> - 2010-12-08 06:13:17
|
Segher Boessenkool wrote: > many MacOSX users will grab the zip file. Unf. Is there a more Macish format that we could use to keep them from zip? mpkg or dmg maybe? > Maybe you want Pete to make snapshots off his tree, He already does make snapshots now and then. But I want to have something general and automated to relieve that manual work. Also for other repos. And my idea is that pushing an annotated tag (maybe signed?) to libusb.git is all that will be needed to create a release tarball. I'd be happy to use someone else's script for it. :) Input is the repo and the newly added commit id in whatever way is easy. //Peter |
|
From: Michael P. <mic...@gm...> - 2010-12-08 12:45:51
|
Segher Boessenkool wrote: >> I think so, yes. I'm not sure the zip files gitweb produces will do >> what you want though, wrt line endings. No, of course not, which is why I was guessing it hadn't already been done. But I hadn't heard updates from Peter in many months, so it was just a guess. The fact that it doesn't do it is also why I indicated it was nontrivial. >> I don't think the gitweb-generated tarballs/zipfiles are terribly good >> for not-so-experienced users. Never mind the line endings -- what about >> autoconf and other build requirements. Release-like snapshots are a much >> more robust resource for them. Agreed! You were the one who suggested gitweb. >> As I've also said at least ten times now, if you want to be sure >> git doesn't mangle line endings on those files, you can check them >> in as binary files. Which would mean of course that CRs end up in >> the repo -- all bytes in there do, just like if you checked in a PNG >> file or whatever. If whoever handles the MSVC project files prefers >> to do it another way, that's fine with me. That was Pete's preference. >> Those tags won't end up in the official repo anyway. >> >> Maybe you want Pete to make snapshots off his tree, at least until it >> gets merged? Yes, that's what I said. Per commit, per repo. Pete Batard wrote: >> So we're not going with Peter's "I just don't want CR in the repo"? >> Can Peter confirm he's OK with it? No, Segher is saying that if that happens with the MSVC files, he won't complain. Nobody's necessarily advocating that. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-08 10:27:10
|
On 2010.12.08 04:55, Segher Boessenkool wrote: > As I've also said at least ten times now, if you want to be sure > git doesn't mangle line endings on those files, you can check them > in as binary files. So "-text" (or "-crlf"), which is what I did late July and that caused Michael issues? > Which would mean of course that CRs end up in the repo So we're not going with Peter's "I just don't want CR in the repo"? Can Peter confirm he's OK with it? If yes to the above, then we've been on the same page for MSVC files all along, and we are considering that the issue experienced by Michael will not occur in official. > Maybe you want Pete to make snapshots off his tree, at least until it > gets merged? As Michael pointed out, I already do, as that was requested. I maintain a list of the 6 latest snapshots here [1] and the archive is at [2]. Regards, /Pete [1] http://libusb.org/wiki/windows_backend#LatestBinarySnapshots [2] http://code.google.com/p/libusb-winusb-wip/downloads/list |
|
From: Segher B. <se...@ke...> - 2010-12-08 11:47:18
|
>> As I've also said at least ten times now, if you want to be sure >> git doesn't mangle line endings on those files, you can check them >> in as binary files. > > So "-text" (or "-crlf"), which is what I did late July and that caused > Michael issues? "crlf" is a compatibility option; "-text" does only part of what "binary" does; and you both did not have the attribs on there from the start, and it were different files, as far as I know. I could be mixing things up by now, I hope you understand. >> Which would mean of course that CRs end up in the repo > > So we're not going with Peter's "I just don't want CR in the repo"? > Can Peter confirm he's OK with it? I'm sure he'll be ok with CRs in a PNG file as well. > If yes to the above, then we've been on the same page for MSVC files all > along, And I *said so* since the start. I have no idea why you keep bringing it up! I don't *care* what you do to these files, as long as it doesn't screw up for anyone who doesn't use them. Hopefully you'll make them work for people who _do_ use them as well, of course. > and we are considering that the issue experienced by Michael will > not occur in official. Experiment, see what happens. >> Maybe you want Pete to make snapshots off his tree, at least until it >> gets merged? > > As Michael pointed out, I already do, as that was requested. I think that's very useful for mswindows users with the current state of things being what it is. Thank you. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-08 11:57:20
|
On 2010.12.08 11:47, Segher Boessenkool wrote: > I have no idea why you keep bringing it up! Because we have 2 maintainers who are providing conflicting information! Peter was adamant "I just don't want CR in the repo", while you have been saying that you don't want to care about MSVC files, in which case, unless you explicitly tell Peter that, yes, you want CR in the repo for what he sees as text files and vehemently insited he wants to be treated as text files, I would expect Peter to still impose his choice. It's simple as this really. Now I know for sure that, in direct contradition with Peter, you want CR in the repo for the MSVC files (which is better than "I don't care"), so we just need Peter to confirm that he is OK, which he has yet to do. Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-08 12:04:42
|
Also, I think we still want to see diffs on the MSVC project files, in
which case "-text" ("-crlf") is what we want to go with.
As per [1]
------------------------------------------------------------------------
(If) You do not want any end-of-line conversions applied to, nor textual
diffs produced for, any binary file you track. You would need to specify
e.g.
*.jpg -text -diff
but that may become cumbersome, when you have many attributes. Using
attribute macros, you can specify groups of attributes set or unset at
the same time. The system knows a built-in attribute macro, binary:
*.jpg binary
which is equivalent to the above.
------------------------------------------------------------------------
If binary means we can no longer see the diffs, then I very much think
we want to go with "-text" only.
Regards,
/Pete
[1] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
|
|
From: Segher B. <se...@ke...> - 2010-12-08 13:59:45
|
> Also, I think we still want to see diffs on the MSVC project files, in
> which case "-text" ("-crlf") is what we want to go with.
>
> As per [1]
> ------------------------------------------------------------------------
> (If) You do not want any end-of-line conversions applied to, nor textual
> diffs produced for, any binary file you track. You would need to specify
> e.g.
>
> *.jpg -text -diff
You do not get diffs if you use -diff. That's what -diff means!
You probably do not want -text either. You might want to force a
specific line ending (on checked out files); but I believe someone
said on this thread that that doesn't actually matter, and besides,
your autocrlf setting should take care of it.
But I don't know; see what works. Get consensus amongst mswindows
devs that it does indeed work. Profit!
(I would try doing exactly nothing first; this is the easiest to
get accepted, right).
Segher
|
|
From: Segher B. <se...@ke...> - 2010-12-08 12:30:12
|
> Peter was adamant "I just don't want CR in the repo", while you have
> been saying that you don't want to care about MSVC files, in which case,
> unless you explicitly tell Peter that, yes, you want CR in the repo for
> what he sees as text files and vehemently insited he wants to be treated
> as text files, I would expect Peter to still impose his choice.
I would hope you, as MSVC guy, would figure out how to put the MSVC
files in the repo in such a way that a) everyone who does not use it
has no problems with it, and b) it works fine for all MSVC users.
If you do this, I doubt Peter will care exactly how it's done. I
certainly will not :-)
> Now I know for sure that, in direct
> contradition with Peter, you want CR in the repo for the MSVC files
No: I don't care about those files, not my cup of tea, do whatever
works for them, just make sure that people like me (i.e., users of
all other platforms) do not have to care what you do to those files!
My suggestion to use binary for those files is just that, a suggestion:
it could well be that some text format would be better. Things seem
to point that way, actually. Perhaps even the default would work
("use whatever line ending the user has configured (for this repo)").
I'm sure you guys can figure it out.
Segher
|
|
From: Pete B. <pb...@gm...> - 2010-12-08 13:00:04
|
On 2010.12.08 12:30, Segher Boessenkool wrote: > I would hope you, as MSVC guy, would figure out how to put the MSVC > files in the repo in such a way that a) everyone who does not use it > has no problems with it, and b) it works fine for all MSVC users. I did do exactly that for official. Michael got issues with the introduction of *corrective* changes into experimental aimed at making sure that official would be fine, and people have now ran along with it, without looking at the area with which Michael had an issue, saying it was proof that the proposal wouldn't work. My analysis and everything I've read about git tells me that there's not a chance of Michael's problems happening in official. If someone thinks that analysis is wrong, they are welcome to offer an alternative explanation of how official is expected to break with the proposed -crlf/-text change. To reiterate, Michael problems were in trying to convert an LF file to CRLF, whereas we will *introduce* CRLF files right from the start in official. There will be no LF -> CRLF commit conversion in official that can potentially fail, and if we do things properly, any new Windows file that needs to be CRLF will first have a -text .gitattributes set, and then the file we be added as CRLF. If git behaves how it is supposed to do, we are not running any risks on official with the introduction of -crlf/-text for MSVC files, and I'm hoping that Michael can agree with that too, because then we can come to a resolution, so I will ask him directly. Michael, do you have any reason to expect that the proposed change (-text in gitattributes then adding CRLF files into official) is going to cause issues, like the ones you have seen, on official? If not, then problem solved. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-09 00:22:55
|
Pete Batard wrote: >> Michael, do you have any reason to expect that the proposed change >> (-text in gitattributes then adding CRLF files into official) is going >> to cause issues, like the ones you have seen, on official? I have no idea. If you're wondering why you haven't seen a definite answer from me on that so far, that's why. The only theory I've had so far about why git was acting up has fallen apart again. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-09 01:32:30
|
On 2010.12.09 00:22, Michael Plante wrote: > Pete Batard wrote: >>> Michael, do you have any reason to expect that the proposed change >>> (-text in gitattributes then adding CRLF files into official) is going >>> to cause issues, like the ones you have seen, on official? > > I have no idea. If you're wondering why you haven't seen a definite answer > from me on that so far, that's why. The only theory I've had so far about > why git was acting up has fallen apart again. OK. If you want to think about it further, and try to figure out the issue git is having, fair enough (I'd like to have some logic behind what git does on CRLF conversions too). But while you do that, and I think you're already well aware of it, please remember that we are trying to analyse 2 different issues here (or one real issue and one potential) and that the July commit was only a corrective commit that was applied so that we could introduce a different one for integration. And for people who are still reading this thread, these 2 different commits can be summarized as follows: July commit: "Shoot:, we should never have left MS project files to be stored as LF in the repo while we want them CRLF, so let's fix that while we're experimental." [1] Proposed (official) commit: "Before we introduce the MS project files, let us make sure they are stored as CRLF in the repo" [2], and then add them [3]. Regards, /Pete PS: Ah, [2]. Can't help but wish this one hadn't fallen through the cracks back then... [1] http://git.libusb.org/?p=libusb-pbatard.git;a=commitdiff;h=b5820d34ad6fd3fa719d861daa58e25789ccf232;js=1 [2] http://marc.info/?l=libusb-devel&m=128103042522279&w=2 (NB: now that I read the mail again, I think I did actually find out that I couldn't open LF'd MSVC6 project files when I tested on VMWare) [3] http://marc.info/?l=libusb-devel&m=128103057922488&w=2 |
|
From: Pete B. <pb...@gm...> - 2010-12-09 11:23:50
|
If you look at my last two commits for master [1], you'll see that I have now added a new extension for files with attribute -crlf (*.test) and, on the subsequent commit, I have added a CRLF text file (_testing.test). With this, everybody has the ability to test the proposed MS solution files changes, as I am planning to introduce them to official, and try to find a problem. It would definitely be interesting to confirm that you can indeed incorporate these changes into the branch that caused issues in August, or any other branch that you have for that matter. I've done some limited testing on my end, including merging from my new master into hp [2]. NB: Did this on master rather than a branch, as I want any possibility of blow-up to reach the largest possible audience. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=summary [2] http://git.libusb.org/?p=libusb-pbatard.git;a=commit;h=50a23e3f38b4f6342c5dc102497c7a8b42d7b7bb;js=1 |
|
From: Tim R. <ti...@pr...> - 2010-12-08 18:00:49
|
Michael Plante wrote: > Segher Boessenkool wrote: >>> Zip can handle text vs. binary files. > Yes. But what I'm saying is that Windows users naturally go for a zip file > over a tgz when available. Vice versa in Linux. Right? I certainly do. Although I do have (and rely heavily on) the fabulous UnxUtils tools, and I wrote my own versions of "tar tvfz" and "tar xvfz" as Python scripts, I still tend to trust the zip file handling. For those who are participating in this CRLF discussion and might have been getting cranky at its length, I want to say that I have full and complete sympathy, regardless of how long it takes. Even in our 6-person office, with our simple CVS repository, we have had this exact same battle more than once over the years. It is extremely difficult to come up with a set of options and standards that produces the results everyone wants. That's partly because of faulty assumptions on the part of some, and partly because some tools try to be overly helpful. I very much appreciate the patience of all who are involved here; once the picky folks in this discussion are satisfied, the General Public should benefit greatly. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Peter S. <pe...@st...> - 2010-12-08 02:13:30
|
Michael Plante wrote: > >> 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), That part is already done. I wanted to prepare also for snapshots when I got Trac hooked up to git, so there's an easy way to get notifications on the server for commits now. > and also thinking through any security issues involved in allowing > semi-trusted people to cause the server to publish files in tarball > format. This is an interesting point, but I think it's OK. gitweb actually already can do tarball snapshots for us, though they are not really comparable to release tarballs since autogen hasn't been run. //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-08 01:18:38
|
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 Agree, but I think it will be more the other way around; once we have snapshots working that will work for releases too. :) > > I have not been making a distinction between tarballs and snapshots. > > Is there one? > > _Release_ tarballs, which we should have no matter what. We do have those, they're generated by Daniel using a Makefile rule. Source snapshots would probably be easy enough to set up, but we (I) want binary snapshots too, maybe even more so than source. Maybe that's wrong though, and source snapshots would be fine as well? Hmm. //Peter |
|
From: Segher B. <se...@ke...> - 2010-12-08 01:58:06
|
>> > I have not been making a distinction between tarballs and snapshots. >> > Is there one? >> >> _Release_ tarballs, which we should have no matter what. > > We do have those, they're generated by Daniel using a Makefile rule. So throw it in cron and you have snapshots. Plus or minus a little twiddling for version strings. > Source snapshots would probably be easy enough to set up, but we (I) > want binary snapshots too, maybe even more so than source. What is a "binary snapshot"? Segher |
|
From: Peter S. <pe...@st...> - 2010-12-08 02:17:15
|
Segher Boessenkool wrote: > >> _Release_ tarballs, which we should have no matter what. > > > > We do have those, they're generated by Daniel using a Makefile rule. > > So throw it in cron and you have snapshots. Plus or minus a little > twiddling for version strings. They also upload to SF, and yes assume that it's a particular version. Not big things to fix, but things to fix, and could get something more general running instead, with not much more effort, I think. > > Source snapshots would probably be easy enough to set up, but we (I) > > want binary snapshots too, maybe even more so than source. > > What is a "binary snapshot"? Binary packages at least for Windows, but maybe other systems too. (I e.g. sat in on the end of a debian packaging workshop, that's a good format to reach a lot of users.) //Peter |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-07 13:07:07
|
On Tue, Dec 7, 2010 at 8:39 PM, Michael Plante <mic...@gm...> wrote: > Pete Batard wrote: > 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. > I maintain my opinion that this is not a bug of autotools and bash. They are designed to follow the Unix convention so that they will not work with CRLF. However I was under the impression that nobody in the right mind should set autocrlf=true for cross-platform project (it is certainly fine for Windows only project). But I could be wrong as the popular Github seems to recommend it. Very surprising! http://help.github.com/dealing-with-lineendings/ On the other hand, I think MSysGit's default installer option of autocrlf=true is controversial based on their mailing list. Even the wiki use "much-hated" when it says that "There has been work to choose something different than the much-hated autoCRLF=true option during install: there are options for autoCRLF=false and autoCRLF=input together with explanations, with the latest installers." https://git.wiki.kernel.org/index.php/MSysGit:MSysGitHerald9 Anyway, I am not a git expert and I do not have any problems with whatever you guys decided. I just hope I can continue to use Cygwin Git and the checked-out repo will work under both Cygwin and MinGW. I will not use MSysGit or other git GUIs. -- Xiaofan |
|
From: Peter S. <pe...@st...> - 2010-12-07 20:37:45
|
Xiaofan Chen wrote: > However I was under the impression that nobody in the right mind > should set autocrlf=true for cross-platform project (it is certainly > fine for Windows only project). But I could be wrong as the popular > Github seems to recommend it. Very surprising! I think setting autocrlf=true on Windows is a good idea, because work trees will then use native lineendings. > I just hope I can continue to use Cygwin Git and the checked-out > repo will work under both Cygwin and MinGW. You certainly will. > I will not use MSysGit or other git GUIs. With my suggested .gitattributes, msysGit would also work. //Peter |
|
From: Michael P. <mic...@gm...> - 2010-12-07 23:42:36
|
Xiaofan Chen wrote: >> I will not use MSysGit or other git GUIs. MSysGit is not a GUI. Did you really intend to say "other"? 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