Menu
▾
▴
libusb-devel
|
From: Xiaofan C. <xia...@gm...> - 2010-12-08 00:53:41
|
On Wed, Dec 8, 2010 at 7:42 AM, Michael Plante <mic...@gm...> wrote: > Xiaofan Chen wrote: >>> I will not use MSysGit or other git GUIs. > > MSysGit is not a GUI. Did you really intend to say "other"? > I mane MSysGit and Git GUIs on top of MSysgit (like TortoiseGit). For CVS and SVN, I also use the tools under Cygwin. These tools (cvs, svn, git, etc) work the same under Linux and Cygwin and that is a big plus for me. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-12-07 13:52:33
|
On 2010.12.07 13:06, 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! > 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: Thanks for proving my point that the ____crlf settings seem to be confusing/annoying many people and that we are likely to be better off not relying on them for the files that matter (i.e. everything that must or should have a unique set of line endings across platforms). Regards, /Pete |
|
From: Peter S. <pe...@st...> - 2010-12-07 20:34:02
|
Pete Batard wrote: > my point that the ____crlf settings seem to be confusing/annoying > many people They certainly are. But since they can be quite useful I see no reason that we should not recommend that people use them correctly, if they would like to reap the benefits of doing so. > and that we are likely to be better off not relying on them for the > files that matter As I have tried to show (and verified by testing) what I suggest works regardless of the settings. I'll try to explain the settings. Maybe it can help reduce confusion. core.autocrlf specifies that git should try to automatically determine if each file is text, except those stored with CRLF in the repo. Of course text or -text in .gitattributes skips detection. core.safecrlf is a safetynet for when git does lineending conversion. The setting makes sure that what gets commited can be recreated. core.eol sets the lineending type that files know to git to be text files should have in the work tree. Can be overridden in .gitattributes. These settings encourage all text files to be stored in the repo with LF, and because the default of core.eol is native, a Windows git would only have to set autocrlf=true in order to get native line endings in all work trees, for files that git considers to be text, or that have text in .gitattributes. Very nice I think. safecrlf is a convenient sanity check for the activity in the work tree but never a must-have setting. //Peter |
|
From: Peter S. <pe...@st...> - 2010-12-07 20:02:40
|
Pete Batard wrote: > * eol=lf / eol=crlf and running the risk of having it overridden and > people not getting lf'd files if they use MSYSgit I have always written: text eol=lf That's two attributes. I'm sorry if I should have pointed that out more explicitly - I thought I had already made it clear. Without text in .gitattributes there are certainly many settings that influence git conversion, but text eol=lf is unambiguous. > > users who do not know this stuff are much more likely to use > > tarballs / zipfiles anyway, > > Then you are discriminating. We speak from (in case of Segher, significant) experience. It's not a rule, but it is the common case, thus what we should optimize for. > So far, the only reasons for rejecting -crlf I have seen are: > - *you* don't want CR in the repo > - *you* don't want to constrain LF, even as we know that we want LF > on some files always, as it avoids issues. Allow me to repeat my argument: (for the fourth time, is it?) The files are text, so they should be marked as such. (And for some reason you also keep ignoring that crlf is only a compatibility name, so we should talk only about text vs. -text, not crlf vs. -crlf.) You may understand that it is becoming difficult to discuss this further, when me repeating and trying to clarify myself clearly does not work. :\ > no matter what Peter says, I do NOT trust eol=lf to solve our > problem, With or without text? As I tried to show, without text eol is not of much use at all, and with text it becomes unambiguous. > Maybe Peter is confident in git's line conversion, but, from > experience, I'm not, Maybe it was just configured wrong. There are a fair number of settings to take into account, and it certainly took me several readings of documentation, and some testing, to get a grip on git in this respect. Maybe spent half an hour on it. Followed by a few days of your FUD. Please test, and certainly let us know if there is an actual problem with what I suggested. //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-07 20:41:12
|
On 2010.12.07 20:02, Peter Stuge wrote: > Pete Batard wrote: >> * eol=lf / eol=crlf and running the risk of having it overridden and >> people not getting lf'd files if they use MSYSgit > > I have always written: text eol=lf > > That's two attributes. I'm sorry if I should have pointed that out > more explicitly - I thought I had already made it clear. > > Without text in .gitattributes there are certainly many settings that > influence git conversion, but text eol=lf is unambiguous. Oops. I hadn't realized you could combine two such attributes (how much more non obvious ways of screwing line conversion are there that git users need to be aware of?). That's probably why I couldn't get eol=lf alone to work then (I'll test "text eol=lf" soon) > Allow me to repeat my argument: (for the fourth time, is it?) > > The files are text, so they should be marked as such. The problem I have with text is that it's just a denomination. It was called "crlf", then it was called "text", and it could be changed tomorrow. Let's say this attribute is called "conversion_option_1" (or anything you want, but not "text"), where is the link between having a text file, and wanting to use "conversion_option_1"? It's not because an option is called with a specific name that one should blindly assume that it should apply to all elements that can be qualified as "name", yet you seem to keep arguing that the name of the option is important. How does the designation matter here? Maybe I missed something, but was does "text" actually do (apart from telling git that it might want to apply EOL conversions on it)? The doc states: ---------------------------------------------------------------------- Setting the text attribute on a path enables end-of-line normalization and marks the path as a text file. ---------------------------------------------------------------------- If the second part is related to your text files having to be set as "text" (rather than using the option "text", a.k.a. "crlf", should apply the conversion options that we want to use, on these files, which also happen to be text files), what does "marks the path as a text file" mean? It looks unrelated to enabling EOL conversion since this is specified separately, but since it's mentioned as an extra attribute, I'd expect it to do something. So far I haven't been able to find in the documentation what "marking the path as a text file" does, while I assume that this is related to your it's a text file so it should be set as "text"? Or does it just flip a flag and that's it? > Maybe it was just configured wrong. There are a fair number of > settings to take into account, and it certainly took me several > readings of documentation, and some testing, to get a grip on git > in this respect. Fair enough. > Maybe spent half an hour on it. Followed by a few > days of your FUD. Please test, and certainly let us know if there > is an actual problem with what I suggested. Will do. Regards, /Pete /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-07 20:47:49
|
Also, from the same page [1]: ----------------------------------------------------------------------- eol This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any content checks, effectively setting the text attribute ----------------------------------------------------------------------- I'm not going to use the "effectively setting the text attribute" as an excuse for my previous tests (that was long ago, and I probably didn't read the doc thoroughly then), but you have to admit that between knowing that one should use "text eol=lf" and the doc stating that if you use eol it effectively sets "text" as well, there are good reasons to be very confused... I guess effectively means almost but not quite. Regards, /Pete [1] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html |
|
From: Peter S. <pe...@st...> - 2010-12-07 00:19:45
|
Pete Batard wrote: > please name a good reason why we shouldn't enforce LF on .sh/.ac/.am, Please stop ignoring what I write, and stop assuming that I try to do the opposite of what you want. text eol=lf as I have suggested does exactly what you write above, with or without safecrlf=true+autocrlf=true. Did you test my suggestion and discover an actual problem with it? I was hoping for feedback from testing already in the first reply to the suggestion. If there is a problem maybe we can find a better solution. If you did not test my suggestion, please do that now, and let's continue the discussion afterwards. > (as per Peter's "if you care about libusb you are supposed to care > about CRLF") I never wrote this, and I never meant this with anything that I wrote. In fact I have several times now been very specific that with the suggested settings it doesn't matter if people care about CRLF or not. > inexperienced git users who might modify their options and end up > with CRLF'd .sh/.ac/.am that prevent them from building libusb. You are blowing this out of proportion and creating scenarios that can not happen, will not happen, or should not happen, and that we in any case must not worry about until they actually become a significant problem for us. If a person grabbed source to build and test it they will not likely fiddle around with CRLF settings. (And they do not need to, as I have explained.) If they do fiddle around with CRLF settings, and do so blindly, then they can and should get problems, and they can then either go learn the details (we can help) or simply ignore the issue by rm -rf their clone and cloning again. > Now, if you want to go executive on the decision to not help such > users, that's fine, but you then need to be upfront and explicit > about it, I was hoping for testing and concrete feedback on my suggestion. That's what *I* expect in an open source project, and what happens with pretty much every other developer I have worked with. If you need an executive decision then here we go: We'll use text eol=lf for the minimum of files that require it, because that allows someone who uses git to retrieve our source to choose for themselves if they want CRLF in their worktree or not. They should be aware of the potential for problems if they do want CRLF. But I believe that at least I would be able to help sort out any issue now. > because it goes in direct conflict with the principles that *I* > expect from an open source project, which is *ensuring* that our > users have the freedom to use the source (which includes .sh, etc) > in any way they want, While noble I'm afraid this is unrealistic, or at the very least not worth the effort, in particular for cross-platform projects. //Peter |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-07 00:12:44
|
On Tue, Dec 7, 2010 at 1:44 AM, Segher Boessenkool <se...@ke...> wrote: >> If you think CRLF is native and MinGW/MSys >> is Windows native and thus should use CRLF >> for everything, then you are totally wrong. > > Okay. > > So what _is_ correct line endings for mingw and/or msys? Just LF > on everything? Correct. > I looked at a lot of projects today that use git and supposedly can > be built on mingw or msys; _none_ have anything special for line ending > mentioned in .gitattributes. And that is what I say that I feel this thread is strange. I did not need to do anything special for the git repos I work with. Nothing special needs to be done. Just use the defaults. -- Xiaofan |
|
From: Peter S. <pe...@st...> - 2010-12-06 23:44:46
|
Xiaofan Chen wrote: > I think you guys have some mis-understandings about MSys > and autotools. I'll try to clarify what I meant. > MSys autoconf is to created MSys dependent applications and this > is not what we want, we want to create Windows native binary. I think MinGW is only GCC and toolchain. And MSYS is the environment that allows to run pre-generated configure scripts, to generate Makefiles that will then use MinGW to build native Windows binaries. autoconf would be compiled by MinGW (probably) and run in MSYS. That's why I called it MSYS autoconf. > Secondly MSys still use shell scripts similar to Unix and > Cygwin, you can call it a mini shell environment but nevertheless, > it is similar to Unix and Cygwin when it comes to shell scripts. Yes! This is the primary task of MSYS as I understand it. And it is even the exact same bash as many Unix systems and Cygwin. But not every command line tool is available, so I agree that it can be called minimal. It's also what the M stands for. :) (But I actually think that the default MSYS installation is very competent!) > If you ever use MinGW/MSys, and open the include > files or the shell scripts (many under the bin dir > are shell scripts), you will notice they are not > CRLF. Ok! The include files in my MinGW cross-compiler toolchain are also LF only, but exactly because it is a cross-toolchain I didn't bring it up, since it may have been adjusted to my platform. > If you think CRLF is native and MinGW/MSys > is Windows native and thus should use CRLF > for everything, then you are totally wrong. Thanks for adding this piece of the puzzle! //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-06 15:58:50
|
On 2010.12.06 15:06, Peter Stuge wrote: > Pete Batard wrote: >> But what I have an objection to is not enforcing files that should >> always be LF as LF, > > You seem to not completely understand what I proposed earlier today. > Please read my messages again. I believe what I suggest (text eol=lf) > will give git users freedom to choose their line endings (using > *crlf=true) but still ensure that special needs are met for > autogen.sh and configure.ac. OK, let me go with my old favourite of why I think your solution will not work: scenarios. The premise here is that if a user ever gets a file that should not have the line endings it should have (LF for .ac/.am/,sh, CRLF for MS proj), it's game over. We don't know for sure that MS projs will ever be an issue, but one of the point of this thread is to assume so. Scenario 1: - UNIX developer wants to use libusb in their project (along many other libraries) and choses git to retrieve the source (maybe they want hotplug and we're in the process of integrating it, with no snapshot available). - UNIX developer diligently reads our wiki pages and sees the *crlf advice, and our advice that he should not copy repos from UNIX to Windows. Since he's on UNIX and has no Windows development planned, he leaves *crlf off. => UNIX developer has MS project files with LF endings - 6 months down the line, UNIX developer who has been successful with his project decides to port it to Windows MSVC. Since he already has git on UNIX, and installing git on Windows doesn't seem a necessity, he just decides to pull (he's developing so he might as well test the latest version) and then copy the files over. Obviously, since it's been 6 months, he has forgotten everything about our one line advice not to copy repos. => game over Scenario 2: - Windows developer, libusb, git version - diligently reads our wiki page, and applies the *crlf=true to that he gets CRLF'd files. If the configure.ac text eol=lf works, he is supposed to get LF'd files there. So far so good. - later down the line, while using another git repo, he decides to change his *crlf *options* (why not - if we can advise a set of *options*, others can advise theirs. These are called "options", not "mandatory settings"), and, because he's not that familiar with git, he mistakenly sets them globally (as I understand from Michael, local git repo settings can get overridden) - 6 months later, Windows app was successful, so now he wants to port it to UNIX. For now he decides to pull from libusb official on Windows to see the changes. Now let's say we added a new Makefile.am in the meantime (new samples, etc). Right now, because he modified them globally with that other project, he has *crlf options that may result in the new Makefile.am to ve CRLF'd (not sure about the old ones, so I'll assume they're still LF'd) - copies to a UNIX a system (might not have internet connectivity to the UNIX system, so he's using an USB key), and obviously has forgotten our little rule about not doing so (it's been 6 months!) => game over If you want to dismiss those scenarios as far fetched, fine, but we happen to know that we can address them both with -crlf, so really our choice is between: 1. preventing potential problematic scenarios that we know how to prevent 2. keeping the maintainers happy for no other reason that they... > just do not want any CR in the repo or use -crlf/-text and, as a result, having to make sure that our git users read and re-read our little rules, and have their freedom restricted, unless they want to waste their time. Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-06 23:24:44
|
Pete Batard wrote: >> (as I understand from Michael, local git >> repo settings can get overridden) Well, I'm not sure whether .git/config, ~/.gitconfig, or /etc/gitconfig takes precedence. But if you leave something unset in one, the other might take effect. I was merely saying that posting a file is really inferior to posting the output of "git config -l", because posting a file leaves room for these doubts. Michael |
|
From: Peter S. <pe...@st...> - 2010-12-06 09:47:28
|
Xiaofan Chen wrote: > > Cygwin is *NOT* Windows. So using a Windows tool such as TortoiseGit > > or msysGit to check out something that will be used Cygwin is not > > correct, should not be expected to work, and must not be optimized > > for. Make sure to use a Cygwin tool for Cygwin testing. I guess LF > > may be the native line ending in Cygwin, which would explain why > > Xiaofan never has problems with line endings. > > I just use whatever default Cygwin git is using and I have no issues > with all the git trees I use. Default is to never convert as I understand it. And Cygwin is happy with LF line endings which all projects use. > But I tried to use MSysGit for once and it gave me all kinds of > problems so that I did not use it. Also CRLF problems, or other? Just curious, it should continue to be fine for you to use Cygwin git. > Take note I sometimes copy git repos between Linux/Windows. Ah thanks for pointing this out. Yes, this should indeed work fine - except when a user has safecrlf=true+autocrlf=true to get CRLF, since core.eol=native by default and will thus differ for the two gits. But getting a problem in that case is a healthy indicator that something is wrong. The CRLF worktree should not be copied to a non-CRLF platform. (Cloning from it would however work perfectly.) > On the other hand, so you expect Pete to use MSysGit for > MinGW/MSVC/WDK testing and use Cygwin Git for Cygwin > testing. I am not so sure if he would like to do that. Only with safecrlf=true+autocrlf=true in the worktree for MinGW/MSVC/WDK; ie. only if there are CRLF in the worktree. I do think it would make sense to keep different worktrees for the different systems, but it's not technically a requirement, I believe especially not if the .gitattributes I suggested is added. (Oh, and if it is added I will add it before any other changes to libusb.git. Everyone should then rebase onto at least that commit. This is why it is important to always track upstream HEAD in downstrean repositories.) > To me, it is better not to let the tool be too smart and convert > things automatically. Rather do not touch the line endings. If > something breaks, blame those who use stupid editors to stupid tools. The entire problem is that we would like to be native on Windows, where CRLF is the only truth that ever existed. And I am very happy to be able to push this problem to the capable hands of git, if users want CRLF in their worktrees. I repeat; git doesn't do conversion unless autocrlf=true, which should never be set without safecrlf=true to ensure conversions do not break stuff. So by default things are as you describe; no conversion, and developers must have good tools. On Windows such good tools are less common, so there it is good that safecrlf=true+autocrlf=true can be set by users, who are stuck with tools that will require or produce CRLF. This is how I have been thinking. //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-06 10:58:43
|
On 2010.12.06 09:47, Peter Stuge wrote: > I repeat; git doesn't do conversion unless autocrlf=true, which > should never be set without safecrlf=true to ensure conversions do > not break stuff. If that's the case, then why does git, in its great wisdom, break the 2 options? /Pete |
|
From: Xiaofan C. <xia...@gm...> - 2010-12-06 12:11:45
|
On Mon, Dec 6, 2010 at 5:47 PM, Peter Stuge <pe...@st...> wrote: >> But I tried to use MSysGit for once and it gave me all kinds of >> problems so that I did not use it. > > Also CRLF problems, or other? Just curious, it should continue to be > fine for you to use Cygwin git. > Permission related problems and CRLF problems, I remember. Take note when I use Cygwin git, I do not remember having problems with MinGW/MSys. -- Xiaofan |
|
From: Pete B. <pb...@gm...> - 2010-12-06 10:55:33
|
On 2010.12.06 09:00, Peter Stuge wrote: > CRLF in the repo is unacceptable AFAIK, it is only to *you*. Segher was fine with it (at least at one stage), Orin is fine with it (files should be treated as binary), I most definitely am fine with it, and if Michael sorted out his MS Project file issue, I think he would be fine with it (one of his 3 options was to go with -crlf if he could sort his problem). > since git has the ability to handle > conversion for us as neccessary Very confusingly, as this thread has shown. But sure, it's only a matter of people not reading the git documentation or screwing up their git options. Why would we ever want to help people who don't see getting overly acquainted with git as a productive use of their time? > and it is very helpful to have a rule > without exceptions for this, How so? I only see a cosmetics advantage here: it will look easier on your eye and make the git tree look better, at the expense of git newcomers getting files with improper line terminations. > among other things because it helps > working back an forth between different repositories, as Michael > pointed out. As I tried to point out, the problem experienced by Michael will never happen on official. It can only happen if there exists an LF <-> CRLF conversion in the tree, which will NEVER happen if we go with -crlf and then add all the files that we want CRLF'd, *NONE* of which exist in official right now. Regards, /Pete PS: as to "you shouldn't copy files from an MS git tree to UNIX" or "you should only use cygwin's git", yeah, that will greatly help ANYBODY who wants to help with the Windows backend development and ensure that they don't break things before submitting them back to the list. If you want to help with the Windows backend, YOU MUST: - make sure you set the autocrlf/safecrlf settings EXACTLY AS WE TELL YOU (regardless of what you might be using for other projects) - make sure you only use the git version that is as native as possible to your each of your development environment - never copy files between environments vs (-crlf): "just go ahead and help us - if you're new to git, that's fine too!" Again, how exactly are we not elitists here? |
|
From: Segher B. <se...@ke...> - 2010-12-06 13:11:19
|
>> CRLF in the repo is unacceptable > > AFAIK, it is only to *you*. > > Segher was fine with it (at least at one stage), I never was. I said you can do with the msvc project files whatever you want though; whatever works for msvc users, no one else cares anyway. I suggested binary mode for those, dunno if that works well. Every text file that is used on unix, or cross-platform, should be in the repo as _text_, i.e., LF-only. Segher |
|
From: Peter S. <pe...@st...> - 2010-12-06 23:46:51
|
Segher Boessenkool wrote: > I looked at a lot of projects today that use git and supposedly can > be built on mingw or msys; _none_ have anything special for line > ending mentioned in .gitattributes. Interesting. So what did they have? * No .gitattributes at all? * .gitattributes with text or crlf attributes for some files? * Something else? //Peter |
|
From: Segher B. <se...@ke...> - 2010-12-07 00:07:07
|
>> I looked at a lot of projects today that use git and supposedly can >> be built on mingw or msys; _none_ have anything special for line >> ending mentioned in .gitattributes. > > Interesting. So what did they have? > > * No .gitattributes at all? > * .gitattributes with text or crlf attributes for some files? > * Something else? Some have nothing, some have some merge attributes (special merge strategy for ChangeLog for example), some have some syntax check things (indent stuff, texinfo stuff). None I've seen have line ending attributes (text, crlf). Segher |
|
From: Peter S. <pe...@st...> - 2010-12-07 00:25:35
|
Segher Boessenkool wrote: > So we don't need a .gitattributes at all; at most we need to advise > people to keep core.autocrlf off for our trees. The default is off, so I think most other projects simply assume that people do not touch these settings. I suggested Pete and Michael to set them, so that they would get CRLF line endings in their work trees, since they work on Windows. If that was just misguided of me then I'm even happier with moving on without any .gitattributes, and someone who does want CRLF will have to sort that out on their own. //Peter |
|
From: Segher B. <se...@ke...> - 2010-12-07 00:49:08
|
>> So we don't need a .gitattributes at all; at most we need to advise >> people to keep core.autocrlf off for our trees. > > The default is off, so I think most other projects simply assume that > people do not touch these settings. Agreed, it seems that way. > I suggested Pete and Michael to set them, Ah, it's all your fault! :-P > so that they would get CRLF > line endings in their work trees, since they work on Windows. It seems it doesn't work on the various mswindows environments to have certain files as CRLF; and it does work to have everything as LF. (An exception perhaps is the MSVC project files; I think everyone agrees we should have those marked as binary?) > If that was just misguided of me then I'm even happier with moving on > without any .gitattributes, and someone who does want CRLF will have > to sort that out on their own. That is the best solution for this non-problem I think, yes. Segher |
|
From: Michael P. <mic...@gm...> - 2010-12-07 00:56:15
|
Segher Boessenkool wrote: >> (An exception perhaps is the MSVC project files; I think everyone >> agrees we should have those marked as binary?) No. They should be CRLF text in the working copy, and I don't care how they're stored in the repo. Incidentally, calling things "binary" or "text" and expecting people to assume that the latter means LF is going to confuse people, since DOS and Windows have always assumed the other way around (fopen(filename, "rt") only opens CRLF files, e.g.). Michael |
|
From: Segher B. <se...@ke...> - 2010-12-07 01:12:02
|
>>> (An exception perhaps is the MSVC project files; I think everyone >>> agrees we should have those marked as binary?) > > No. They should be CRLF text in the working copy, and I don't care how > they're stored in the repo. "Binary" means "they are the same everywhere". If they were CRLF when they were checked in, they will be CRLF wherever they are checked out. I don't care one iota how exactly you mark them; that's for the MSVC maintainers to figure out. I simply wanted to once again say that no, I'm not suggesting messing with the MSVC project files :-) > Incidentally, calling things "binary" or "text" and expecting people to > assume that the latter means LF is going to confuse people, since DOS and > Windows have always assumed the other way around (fopen(filename, "rt") > only > opens CRLF files, e.g.). "text" for git means "do whatever line ending conversions you asked for", etc. It's the default on all files. It does not mean "LF". Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-07 12:17:53
|
On 2010.12.07 01:11, Segher Boessenkool wrote: > "text" for git means "do whatever line ending conversions you asked > for", etc. It's the default on all files. It does not mean "LF". So does that mean you can have "text" that is CRLF in the repo? If not, then maybe I'm missing something, but I still don't get how "text" does not equate "LF" Regards, /Pete |
|
From: Michael P. <mic...@gm...> - 2010-12-07 12:44:49
|
Pete Batard wrote: >> On 2010.12.07 01:11, Segher Boessenkool wrote: >> > "text" for git means "do whatever line ending conversions you asked >> > for", etc. It's the default on all files. It does not mean "LF". >> >> [...] I still don't get how >> "text" does not equate "LF" I've seen both assumptions throughout this thread, which is why I pointed this out. Segher's response is on the same page with me. Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-07 13:40:01
|
On 2010.12.07 12:44, Michael Plante wrote: > Pete Batard wrote: >>> On 2010.12.07 01:11, Segher Boessenkool wrote: >>>> "text" for git means "do whatever line ending conversions you asked >>>> for", etc. It's the default on all files. It does not mean "LF". >>> >>> [...] I still don't get how >>> "text" does not equate "LF" > > I've seen both assumptions throughout this thread, which is why I pointed > this out. Segher's response is on the same page with me. I'm considering text from the point of view of the repo, so maybe that's my mistake. Our prime concern is what ends up in the repo, because all the rest derives from this. If a repo is always LF, then, as far as I know, it is not possible to use "text" ever and end up with LF files in it, hence, from the point of view of the repo, text equates LF, because the git executable on the end user platform will ensure that, no matter what conversion options are used, and no matter whether the file on the file system uses, the file ends up as LF in the repo. I guess there are 2 aspects of text, one is input (how it affects files that are copied into the repo - and my understanding is that if you have text, you will end up with LF always, no matter your conversion options) and the other is output, which is the part where "text" can be interpreted as "do whatever line ending conversions you asked for" So, equating text to LF depends at which end you stand. When standing at the repository end (filesystem -> repo), can there exist any cases where "text" does not equate "LF"? 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