{"thread":{"id":"23705","subject":"What should be the CRLF policy when win + Linux?","startedAt":"2010-05-05T10:01:07Z","lastAt":"2010-05-18T15:13:50Z","messageCount":82,"participants":["mat","Ramkumar Ramachandra","hasen j","Wilbert van Dolleweerd","Erik Faye-Lund","Linus Torvalds","Eyvind Bernhardsen","Avery Pennarun","Gelonida","Junio C Hamano","Nicolas Pitre","Finn Arne Gangstad","A Large Angry SCM","Robert Buck","Dmitry Potapov","Anthony W. Youngman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140976","messageId":"4BE141E3.2060904@gmail.com","threadId":"23705","inReplyTo":null,"subject":"What should be the CRLF policy when win + Linux?","fromName":"mat","fromEmail":"matthieu.stigler@gmail.com","sentAt":"2010-05-05T10:01:07Z","receivedAt":"2010-05-05T10:01:07Z","isPatch":false,"sender":{"key":"matthieu.stigler@gmail.com","avatar":null},"body":"Hi\n\nI have two git projects:\n-one (A) with linux people only\n-one (B) with someone using windows\n\nAs we had \"end of line\" problems with the person using windows (B), I used:\n\ngit config --global core.autocrlf true\n\nFollowing advices from:\nhttp://help.github.com/dealing-with-lineendings/\n\nSo everything now if fine with project B, but now some problems using \nproject (A): I wanted to copy the whole project file to another dir, and \nnow it is complaining about the change, signaling warning:\n\nCRLF will be replaced by LF in .../A.\n\nSo I don't know exactly what I should do...Should I change all the CRLF \nfrom project A, but people will have also problems, or can I switch the \nconfig, once I'm using project A and B? It is not so clear in my mind \nand I would appreciate any advice!!\n\nThanks a lot\n\nMatthieu Stigler\n"},{"id":"140982","messageId":"t2wf3271551005050627jbe328d84q23a85a1e5dced082@mail.gmail.com","threadId":"23705","inReplyTo":"4BE141E3.2060904@gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-05-05T13:27:58Z","receivedAt":"2010-05-05T13:27:58Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nOn Wed, May 5, 2010 at 12:01 PM, mat wrote:\n> So I don't know exactly what I should do...Should I change all the CRLF from\n> project A, but people will have also problems, or can I switch the config,\n> once I'm using project A and B? It is not so clear in my mind and I would\n> appreciate any advice!!\n\nI'm not sure what you should be doing because I've never worked with\nWindows, but the following information might be useful: Yes, you can\nhave project-specific config quite easily.\n\nIn the command\n> git config --global core.autocrlf true\njust drop `--global` and the setting becomes repository-specific.\n\n-- Ram\n"},{"id":"141022","messageId":"x2h600158c31005051935i6f379a9j6aa36b4503776b87@mail.gmail.com","threadId":"23705","inReplyTo":"4BE141E3.2060904@gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-06T02:35:24Z","receivedAt":"2010-05-06T02:35:24Z","isPatch":false,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 5 May 2010 04:01, mat wrote:\n>\n> Hi\n>\n> I have two git projects:\n> -one (A) with linux people only\n> -one (B) with someone using windows\n>\n> As we had \"end of line\" problems with the person using windows (B), I used:\n>\n> git config --global core.autocrlf true\n>\n> Following advices from:\n> http://help.github.com/dealing-with-lineendings/\n>\n> So everything now if fine with project B, but now some problems using project (A): I wanted to copy the whole project file to another dir, and now it is complaining about the change, signaling warning:\n>\n> CRLF will be replaced by LF in .../A.\n>\n> So I don't know exactly what I should do...Should I change all the CRLF from project A, but people will have also problems, or can I switch the config, once I'm using project A and B? It is not so clear in my mind and I would appreciate any advice!!\n>\n> Thanks a lot\n>\n> Matthieu Stigler\n\nI personally find that autocrlf causes more confusion than it solves problems.\n\nI've yet to see a text editor on windows that can't handle \\n line\nendings. (Notepad doesn't count)\n\nJust keep the project with \\n line endings, disable autocrlf, and make\nsure that people are aware of this.\n"},{"id":"141042","messageId":"o2ved79be1d1005060029n67f451c6p3b48b83c51031222@mail.gmail.com","threadId":"23705","inReplyTo":"x2h600158c31005051935i6f379a9j6aa36b4503776b87@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Wilbert van Dolleweerd","fromEmail":"wilbert@arentheym.com","sentAt":"2010-05-06T07:29:35Z","receivedAt":"2010-05-06T07:29:35Z","isPatch":false,"sender":{"key":"wilbert@arentheym.com","avatar":"https://gravatar.com/avatar/781148004f6b87d06fb292344721b83d353d1ba510c59b4dce9ac3feba78150e?d=mp&s=160"},"body":"> I personally find that autocrlf causes more confusion than it solves problems.\n>\n> I've yet to see a text editor on windows that can't handle \\n line\n> endings. (Notepad doesn't count)\n>\n> Just keep the project with \\n line endings, disable autocrlf, and make\n> sure that people are aware of this.\n\nEditors may handle it gracefully but older Windows programs will have problems.\n\nFor instance, Visual Studio 6 will barf on Visual Basic projectfiles\nwith non-windows line-style endings. (And please don't ask why I know\nthis....)\n\n-- \nKind regards,\n\nWilbert van Dolleweerd\nBlog: http://walkingthestack.blogspot.com/\nTwitter: http://www.twitter.com/wvandolleweerd\n"},{"id":"141057","messageId":"4BE28B6C.3070302@gmail.com","threadId":"23705","inReplyTo":"t2wf3271551005050627jbe328d84q23a85a1e5dced082@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"mat","fromEmail":"matthieu.stigler@gmail.com","sentAt":"2010-05-06T09:27:08Z","receivedAt":"2010-05-06T09:27:08Z","isPatch":false,"sender":{"key":"matthieu.stigler@gmail.com","avatar":null},"body":"Thanks for your answer!!\n\nI think what you suggest Ramkumar is indeed what I need, great! The \nsuggestion from hasan to keep with those settings was not doable as the \nwindows guy had the problem of that after even a clean cloning, git was \nsignaling changes (see: http://help.github.com/dealing-with-lineendings/)\n\nSo I just did:\n\n git config --global --unset core.autocrlf\n\nand then set for this specifical project:\n\n git config core.autocrlf true\n\nHope this is how you meant?\n\nThanks a lot!!\n\nMatthieu\n\nRamkumar Ramachandra a écrit :\n> Hi,\n>\n> On Wed, May 5, 2010 at 12:01 PM, mat wrote:\n> \n>> So I don't know exactly what I should do...Should I change all the CRLF from\n>> project A, but people will have also problems, or can I switch the config,\n>> once I'm using project A and B? It is not so clear in my mind and I would\n>> appreciate any advice!!\n>> \n>\n> I'm not sure what you should be doing because I've never worked with\n> Windows, but the following information might be useful: Yes, you can\n> have project-specific config quite easily.\n>\n> In the command\n> \n>> git config --global core.autocrlf true\n>> \n> just drop `--global` and the setting becomes repository-specific.\n>\n> -- Ram\n> \n"},{"id":"141062","messageId":"k2x40aa078e1005060303xcd6aa177n73edc81e850d080e@mail.gmail.com","threadId":"23705","inReplyTo":"4BE28B6C.3070302@gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-05-06T10:03:44Z","receivedAt":"2010-05-06T10:03:44Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, May 6, 2010 at 11:27 AM, mat wrote:\n> Thanks for your answer!!\n>\n> I think what you suggest Ramkumar is indeed what I need, great! The\n> suggestion from hasan to keep with those settings was not doable as the\n> windows guy had the problem of that after even a clean cloning, git was\n> signaling changes (see: http://help.github.com/dealing-with-lineendings/)\n>\n\nThis is a symptom that someone checked in files with CRLF into the\nrepo with core.autocrlf disabled, and the Windows guy having\ncore.autocrlf enabled.\n\nI don't quite agree with Hasen about checking out LF on Windows,\nthough. There's just too many tools that gets slightly confused (as\nwell as some getting REALLY confused) by this in my experience. It's\nsometimes the best trade-off, but quite often not IMO.\n\nWhat I'd do, is to set core.autocrlf to \"input\" on non-Windows\nmachines, and \"true\" on Windows-machines. This makes sure that no\nmachines will check in CRLF. If there's already files checked in with\nCRLF (as seems to be the case with your repo), the Windows-people will\nbe annoyed. So you'd need to make sure that the repo only contained\nCRLFs, and you have basically two options:\n1) Just call dos2unix on all files and commit the changes. This will\nstill cause problems for the Windows users if they need to check out\ncommits older than the dos2unix one.\n2) Use git filter-branch to rewrite the history to pretend no one ever\nmade the mistake of committing CRLFs. This will make trouble for\nanyone who's working on a branch. But it's a one-time issue (unless\nsomeone manages to commit CRLF-files again, that is).\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"141072","messageId":"i2i600158c31005060834s72e10fb7te19048e3b174d29b@mail.gmail.com","threadId":"23705","inReplyTo":"o2ved79be1d1005060029n67f451c6p3b48b83c51031222@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-06T15:34:43Z","receivedAt":"2010-05-06T15:34:43Z","isPatch":false,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 6 May 2010 01:29, Wilbert van Dolleweerd wrote:\n>> I personally find that autocrlf causes more confusion than it solves problems.\n>>\n>> I've yet to see a text editor on windows that can't handle \\n line\n>> endings. (Notepad doesn't count)\n>>\n>> Just keep the project with \\n line endings, disable autocrlf, and make\n>> sure that people are aware of this.\n>\n> Editors may handle it gracefully but older Windows programs will have problems.\n>\n> For instance, Visual Studio 6 will barf on Visual Basic projectfiles\n> with non-windows line-style endings. (And please don't ask why I know\n> this....)\n>\n\nWell, this is the exception that proves the rule then :)\n\nAnyway, If it's a VB project, might as well just keep the files with\nCRLF endings then.\n\nI don't know all linux editors, but I've yet to see one that can't\nhandle CRLF endings.\n"},{"id":"141075","messageId":"alpine.LFD.2.00.1005061009020.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"i2i600158c31005060834s72e10fb7te19048e3b174d29b@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-06T17:15:12Z","receivedAt":"2010-05-06T17:15:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 6 May 2010, hasen j wrote:\n> \n> I don't know all linux editors, but I've yet to see one that can't\n> handle CRLF endings.\n\nA _lot_ of UNIX editors will handle CRLF endings, but if you change a \nfile, they often write the result back with _mixed_ endings. Some will \nalso show the CR as '^M' or some other garbage at the end.\n\nA number of tools will also end up confused, including very fundamental \nthings like \"grep\". Try this:\n\n\techo -e \"Hello\\015\" > f\n\tgrep 'Hello$' f\n\nand notice how the grep does _not_ find the Hello at the end of the line, \nbecause grep sees another random character there (this might be \nunportable, I could easily imagine some versions of grep finding it).\n\nSo I would strongly suggest against CRLF on UNIX. It really doesn't work \nvery well, even if some tools will handle it to some limited degree.\n\nIn short: having 'core.autocrlf' set will likely make it much more \npleasant to work across different platforms. \n\n\t\t\tLinus\n"},{"id":"141076","messageId":"k2s40aa078e1005061026x277757f4pae151c4d312eb3de@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005061009020.901@i5.linux-foundation.org","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-05-06T17:26:34Z","receivedAt":"2010-05-06T17:26:34Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, May 6, 2010 at 7:15 PM, Linus Torvalds\n wrote:\n>\n>\n> On Thu, 6 May 2010, hasen j wrote:\n>>\n>> I don't know all linux editors, but I've yet to see one that can't\n>> handle CRLF endings.\n>\n> A _lot_ of UNIX editors will handle CRLF endings, but if you change a\n> file, they often write the result back with _mixed_ endings.\n\nJust for completeness: The inverse is also the case on Windows; a lot\nof editors will handle LF endings, but a handful of them will insert\ngladly insert CRLFs under certain circumstances. Microsoft Visual\nStudio is one of these.\n\nSo yeah, neither CRLF or LF everywhere is generally a good idea.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"141080","messageId":"h2x600158c31005061300tfe485e01x251ae20b22ef5b27@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005061009020.901@i5.linux-foundation.org","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-06T20:00:58Z","receivedAt":"2010-05-06T20:00:58Z","isPatch":false,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 6 May 2010 11:15, Linus Torvalds wrote:\n>\n>\n> On Thu, 6 May 2010, hasen j wrote:\n>>\n>> I don't know all linux editors, but I've yet to see one that can't\n>> handle CRLF endings.\n>\n> A _lot_ of UNIX editors will handle CRLF endings, but if you change a\n> file, they often write the result back with _mixed_ endings. Some will\n> also show the CR as '^M' or some other garbage at the end.\n>\n> A number of tools will also end up confused, including very fundamental\n> things like \"grep\". Try this:\n>\n>        echo -e \"Hello\\015\" > f\n>        grep 'Hello$' f\n>\n> and notice how the grep does _not_ find the Hello at the end of the line,\n> because grep sees another random character there (this might be\n> unportable, I could easily imagine some versions of grep finding it).\n>\n> So I would strongly suggest against CRLF on UNIX. It really doesn't work\n> very well, even if some tools will handle it to some limited degree.\n>\n> In short: having 'core.autocrlf' set will likely make it much more\n> pleasant to work across different platforms.\n>\n>                        Linus\n>\n\nWhen I'm on windows, I prefer LF (unless the project already uses\nCRLF, or it's outside my control).\n\nVB is very windowsy; I *really* doubt most VB developers use (or even\nknow) grep, so I don't think it's a problem if a VB project\nstandardizes line endings to be CRLF.\n\nMy problem with autocrlf is that, well, it converts line endings in\nthe working directory to CRLF, even though I don't always want it to.\n(most of the time, I don't).\n\nThe other problem is, git will get confused if you set autocrlf *after\nthe fact*; i.e. you already cloned and have the files checked out,\nmaybe even made some commits.\n\nOverall, I ran into many awkward situations with autocrlf (and I can't\nremember them now), but if you google you can find some of the issues\npeople are having.\n\nThe whole problem would go away if there was no crlf, and that's not\nimpossible: any decent text editor can read/write files with Unix line\nendings.\n\nI wasn't aware that Visual Studio doesn't have an easy way to have it\nwrite LF endings by default; I'm sure there are addons to make that\neasier. Plus most open source projects are not usually setup with VS\nas the development environment anyway, so it's really not a big\nproblem.\n\nSo yeah, I think LF everywhere is the better way to go most of the time.\n"},{"id":"141083","messageId":"alpine.LFD.2.00.1005061317250.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"h2x600158c31005061300tfe485e01x251ae20b22ef5b27@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-06T20:23:56Z","receivedAt":"2010-05-06T20:23:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 6 May 2010, hasen j wrote:\n> \n> My problem with autocrlf is that, well, it converts line endings in\n> the working directory to CRLF, even though I don't always want it to.\n> (most of the time, I don't).\n\nYou can just set it to 'input' if you want to. It's not just on/off, you \ncan also say \"I want to check out with no conversion (ie \"just LF\"), but \nconvert CRLF to LF on input\".\n\nBtw, one thing to keep in mind with autocrlf is the \"auto\" part: it tries \nto do a good job noticing when something is text vs binary, but it _is_ a \nheuristic. I think it's a pretty good one, but if you do set autocrlf \n(whether to \"true\" or to \"input\"), at least think about attributes (\"man \ngitattributes\")\n\n\t\tLinus\n"},{"id":"141086","messageId":"x2s40aa078e1005061340vaf404ab3g30b2b98ca408205@mail.gmail.com","threadId":"23705","inReplyTo":"h2x600158c31005061300tfe485e01x251ae20b22ef5b27@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-05-06T20:40:00Z","receivedAt":"2010-05-06T20:40:00Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, May 6, 2010 at 10:00 PM, hasen j wrote:\n> On 6 May 2010 11:15, Linus Torvalds wrote:\n>>\n>>\n>> On Thu, 6 May 2010, hasen j wrote:\n>>>\n>>> I don't know all linux editors, but I've yet to see one that can't\n>>> handle CRLF endings.\n>>\n>> A _lot_ of UNIX editors will handle CRLF endings, but if you change a\n>> file, they often write the result back with _mixed_ endings. Some will\n>> also show the CR as '^M' or some other garbage at the end.\n>>\n>> A number of tools will also end up confused, including very fundamental\n>> things like \"grep\". Try this:\n>>\n>>        echo -e \"Hello\\015\" > f\n>>        grep 'Hello$' f\n>>\n>> and notice how the grep does _not_ find the Hello at the end of the line,\n>> because grep sees another random character there (this might be\n>> unportable, I could easily imagine some versions of grep finding it).\n>>\n>> So I would strongly suggest against CRLF on UNIX. It really doesn't work\n>> very well, even if some tools will handle it to some limited degree.\n>>\n>> In short: having 'core.autocrlf' set will likely make it much more\n>> pleasant to work across different platforms.\n>>\n>>                        Linus\n>>\n>\n> When I'm on windows, I prefer LF (unless the project already uses\n> CRLF, or it's outside my control).\n>\n\n\"When I'm on windows\" leads me to believe Windows is not your primary\noperating system. If not, please excuse me.\n\n> My problem with autocrlf is that, well, it converts line endings in\n> the working directory to CRLF, even though I don't always want it to.\n> (most of the time, I don't).\n>\n\nThere's gitattributes for that.\n\n> The other problem is, git will get confused if you set autocrlf *after\n> the fact*; i.e. you already cloned and have the files checked out,\n> maybe even made some commits.\n>\n\ncore.autocrlf being on by default in Git for Windows greatly reduces\nthe risk for this. I with core.autocrlf was set to \"input\" by default\non other platforms, though.\n\n> Overall, I ran into many awkward situations with autocrlf (and I can't\n> remember them now), but if you google you can find some of the issues\n> people are having.\n>\n> The whole problem would go away if there was no crlf, and that's not\n> impossible: any decent text editor can read/write files with Unix line\n> endings.\n>\n\nThat's probably on of the things that makes a text-editor decent in\nyour book, but this opinion might not be shared with everyone. Perhaps\nnot being primarily a Windows-user somehow biases your opinion here?\n\n> I wasn't aware that Visual Studio doesn't have an easy way to have it\n> write LF endings by default; I'm sure there are addons to make that\n> easier. Plus most open source projects are not usually setup with VS\n> as the development environment anyway, so it's really not a big\n> problem.\n\nThe problem with Visual Studio isn't that it doesn't write LFs\nnormally... the problem is that when you paste text, it retains the\nnewline style from the source you copied from. But it is not the only\ntool with such issues, so playing the \"VS is the problem\"-card doesn't\nstick IMO.\n\nEven if it did, Open source isn't the only model for developing\nsoftware. And again... even if it were, working well together with\nvisual studio support would be very beneficial for quite a bit of\nprojects. Visual Studio is probably the most used code-editor among\nWindows-developers (with a good margin too, I suspect), so ignoring it\nis would just be sticking your head in the sand - or worse, asking for\nless contributions from Windows-users (which can often be a problem in\nthe first place).\n\nSo no, I strongly doubt LF everywhere is the better way ;)\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"141091","messageId":"w2h600158c31005061514m1fc1e75ay9096eb27d9a1a4ba@mail.gmail.com","threadId":"23705","inReplyTo":"x2s40aa078e1005061340vaf404ab3g30b2b98ca408205@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-06T22:14:10Z","receivedAt":"2010-05-06T22:14:10Z","isPatch":false,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":">>\n>> When I'm on windows, I prefer LF (unless the project already uses\n>> CRLF, or it's outside my control).\n>>\n>\n> \"When I'm on windows\" leads me to believe Windows is not your primary\n> operating system. If not, please excuse me.\n\nI used to be, I only moved to linux about a year ago, but I use\nwindows at work, and I started using git when I was on windows.\n\n> Open source isn't the only model for developing software.\n\nBut it's probably the most common scenario where people run into line\nending issues.\n\nIf the project is a VS project, then it's probably not multi-platform,\nplus everyone at the company would be using windows anyway, so there's\nno line-ending issue.\n\n> And again... even if it were, working well together with\n> visual studio support would be very beneficial for quite a bit of\n> projects. Visual Studio is probably the most used code-editor among\n> Windows-developers (with a good margin too, I suspect), so ignoring it\n> is would just be sticking your head in the sand - or worse, asking for\n> less contributions from Windows-users (which can often be a problem in\n> the first place).\n\nThe problem can be avoided with a little bit of education. VS is not a\nmultiplatform IDE anyway\nSure, it can't work with LF endings as well as notepad++, but it's not\ngit's responsibility to try to fix that.\n\nI just don't think it's a big enough issue to be built into git.\n\nIMHO it's much better to work around the problem (if and when it\narises) by using clean and smudge filters in .gitattributes, than\nhaving it built in and enabled by default in the msysgit installer.\n"},{"id":"141093","messageId":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","threadId":"23705","inReplyTo":"x2s40aa078e1005061340vaf404ab3g30b2b98ca408205@mail.gmail.com","subject":"[PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-06T22:27:32Z","receivedAt":"2010-05-06T22:27:32Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"This discussion couldn't be more timely, as I've recently acquired a\ndesperate need to solve CRLF problems at $dayjob. This patch series\nintroduces a new way of turning on autocrlf normalization by splitting\nthe configuration into two:\n\n- An attribute called \"auto-eol\" is set in the repository to turn on\n normalization of line endings. Since attributes are content, the\n setting is copied when the repository is cloned and can be changed in\n an existing repository (with a few caveats). Setting this attribute\n is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n\n- A configuration variable called \"core.eolStyle\" determines which type\n of line endings are used when checking files out to the working\n directory.\n\nHow does this solve the current problems with core.autocrlf? First,\nlet's enumerate them:\n\n\n1. Setting core.autocrlf in your global or system configuration is a\npain since git will get confused whenever you work in a repository which\ncontains CRLF line endings. If you have to work in both repositories\nwith normalization and repositories with mixed line endings, you have no\nchoice but to set core.autocrlf in each repository individually.\n\n2. Setting core.autocrlf in an individual repository would be okay\nexcept that naive users will do it after they have already cloned:\nunless core.autocrlf is set globally, the clone will have the wrong line\nendings, and the user needs to know how to refresh it manually (rm -rf *\n&& git checkout -f).\n\n3. Once somebody does it, _everyone_ has to do it: if someone checks in\na file with CRLFs, that file will cause trouble for everyone who has\nautocrlf set. That someone can be a Linux user who just copied a file\nfrom Windows and didn't think to convert the line endings (BT, DT).\n\n4. Once a repository contains CRLFs autocrlf can never sanely be\nenabled; the CRLFs can be normalized in a commit, but there's no way to\nsay \"all commits after this one are normalized, those that came before\nwere not\".\n\n5. On the other hand, setting core.autocrlf means that git no longer\nstores your files in their pristine, natural state; if you _know_ that\nyour repository will never be used by anyone whose EOL preference\ndiffers from your own, it seems wasteful and dangerous to normalize\nthose line endings.\n\n\nI used an attribute to enable line-ending conversion because it seems to\nbe a good idea to have line ending normalization be a property of the\ncontent rather than the repository's or user's configuration. \"If\nanybody wants to clone my repository, they'd better be prepared to\nnormalize their EOLs\".\n\nWhich EOLs the user wants to use obviously can't be a part of the\ncontent, so part is still a configuration variable.\n\n\"core.autocrlf\" is still available and allows someone working on, say,\ngit.git from Windows to have CRLFs in their working directory without\nrequiring any changes to the repository.\n\nFor backwards compatibility, \"core.autocrlf\" overrides \"auto-eol\" if it\nis set, and \"core.eolStyle\" can be set to \"false\" to disable conversion\neven when \"auto-eol\" is set. \n\nFor my own part, I'll be implementing this change company-wide shortly.\nWe have an existing repository with a large body of code that contains a\nheady mix of CRLF and LF files, but our newly introduced build system\nrequires everything to be normalized to CRLF (don't ask). There's no\nsane way of handling this using autocrlf; all developers would have to\nknow when to set core.autocrlf and remember to set it on every clone, or\neven on every checkout.\n\nI hope someone else will find it useful.\n\nEyvind Bernhardsen (3):\n Add \"auto-eol\" attribute and \"core.eolStyle\" config variable\n Add tests for per-repository eol normalization\n Add per-repository eol normalization\n\n Documentation/config.txt | 11 ++-\n Documentation/gitattributes.txt | 92 +++++++++++++++++---\n Makefile | 3 +\n cache.h | 19 ++++\n config.c | 16 +++-\n convert.c | 48 ++++++++---\n environment.c | 1 +\n t/t0025-auto-eol.sh | 180 +++++++++++++++++++++++++++++++++++++++\n 8 files changed, 339 insertions(+), 31 deletions(-)\n create mode 100755 t/t0025-auto-eol.sh\n"},{"id":"141095","messageId":"a8bc571bb092967a1e481f74f3e97ced5135ff34.1273183206.git.eyvind.bernhardsen@gmail.com","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC 1/3] Add \"auto-eol\" attribute and \"core.eolStyle\" config variable","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-06T22:27:33Z","receivedAt":"2010-05-06T22:27:33Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Introduce a new attribute called \"auto-eol\" and a config variable,\n\"core.eolStyle\", which will enable line ending normalisation using the\nautocrlf mechanism.\n\nThe intent is to enable autocrlf in an alternative way, splitting the\nexisting \"core.autocrlf\" config variable into two:\n\n- a per-repository \"line endings should be normalised in this\n repository\" setting, activated by setting the auto-eol attribute\n (usually on all files in the repository)\n\n- a config variable, \"core.eolStyle\" which lets the user decide which\n line endings are preferred in the working directory\n\nPossible values for \"core.eolStyle\" are:\n\n- \"lf\", meaning that LF line endings are preferred\n- \"crlf\", meaning that CRLF line endings are preferred\n- \"native\" (the default), crlf or lf according to platform\n- \"false\", which disables end-of-line conversion even when auto-eol is\n set\n\n\"core.autocrlf\" will override auto-eol when set to anything but \"false\".\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Makefile | 3 +++\n cache.h | 19 +++++++++++++++++++\n config.c | 16 +++++++++++++++-\n environment.c | 1 +\n 4 files changed, 38 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 910f471..419532e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -224,6 +224,8 @@ all::\n #\n # Define CHECK_HEADER_DEPENDENCIES to check for problems in the hard-coded\n # dependency rules.\n+#\n+# Define NATIVE_CRLF if your platform uses CRLF for line endings.\n \n GIT-VERSION-FILE: FORCE\n \t@$(SHELL_PATH) ./GIT-VERSION-GEN\n@@ -989,6 +991,7 @@ ifeq ($(uname_S),Windows)\n \tNO_CURL = YesPlease\n \tNO_PYTHON = YesPlease\n \tBLK_SHA1 = YesPlease\n+\tNATIVE_CRLF = YesPlease\n \n \tCC = compat/vcbuild/scripts/clink.pl\n \tAR = compat/vcbuild/scripts/lib.pl\ndiff --git a/cache.h b/cache.h\nindex 5eb0573..690511e 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -561,6 +561,25 @@ enum safe_crlf {\n \n extern enum safe_crlf safe_crlf;\n \n+enum auto_crlf {\n+\tAUTO_CRLF_FALSE = 0,\n+\tAUTO_CRLF_TRUE = 1,\n+\tAUTO_CRLF_INPUT = -1,\n+};\n+\n+enum eol_style {\n+\tEOL_STYLE_FALSE = AUTO_CRLF_FALSE,\n+\tEOL_STYLE_CRLF = AUTO_CRLF_TRUE,\n+\tEOL_STYLE_LF = AUTO_CRLF_INPUT,\n+#ifdef NATIVE_CRLF\n+\tEOL_STYLE_NATIVE = EOL_STYLE_CRLF,\n+#else\n+\tEOL_STYLE_NATIVE = EOL_STYLE_LF,\n+#endif\n+};\n+\n+extern enum eol_style eol_style;\n+\n enum branch_track {\n \tBRANCH_TRACK_UNSPECIFIED = -1,\n \tBRANCH_TRACK_NEVER = 0,\ndiff --git a/config.c b/config.c\nindex 6963fbe..8a11052 100644\n--- a/config.c\n+++ b/config.c\n@@ -461,7 +461,7 @@ static int git_default_core_config(const char *var, const char *value)\n \n \tif (!strcmp(var, \"core.autocrlf\")) {\n \t\tif (value && !strcasecmp(value, \"input\")) {\n-\t\t\tauto_crlf = -1;\n+\t\t\tauto_crlf = AUTO_CRLF_INPUT;\n \t\t\treturn 0;\n \t\t}\n \t\tauto_crlf = git_config_bool(var, value);\n@@ -477,6 +477,20 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.eolstyle\")) {\n+\t\tif (value && !strcasecmp(value, \"lf\"))\n+\t\t\teol_style = EOL_STYLE_LF;\n+\t\telse if (value && !strcasecmp(value, \"crlf\"))\n+\t\t\teol_style = EOL_STYLE_CRLF;\n+\t\telse if (value && !strcasecmp(value, \"native\"))\n+\t\t\teol_style = EOL_STYLE_NATIVE;\n+\t\telse if (! git_config_bool(var, value))\n+\t\t\teol_style = EOL_STYLE_FALSE;\n+\t\telse\n+\t\t\treturn error(\"Malformed value for %s\", var);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"core.notesref\")) {\n \t\tnotes_ref_name = xstrdup(value);\n \t\treturn 0;\ndiff --git a/environment.c b/environment.c\nindex 876c5e5..05cd1d5 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -40,6 +40,7 @@ const char *editor_program;\n const char *excludes_file;\n int auto_crlf = 0;\t/* 1: both ways, -1: only when adding git objects */\n int read_replace_refs = 1;\n+enum eol_style eol_style = EOL_STYLE_NATIVE;\n enum safe_crlf safe_crlf = SAFE_CRLF_WARN;\n unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;\n enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;\n-- \n1.7.1.3.gb95c9\n"},{"id":"141096","messageId":"38d9735b135503ca444e82d3aaa9107ea18439e6.1273183206.git.eyvind.bernhardsen@gmail.com","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC 2/3] Add tests for per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-06T22:27:34Z","receivedAt":"2010-05-06T22:27:34Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"\nSigned-off-by: Eyvind Bernhardsen \n---\n t/t0025-auto-eol.sh | 180 +++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 180 insertions(+), 0 deletions(-)\n create mode 100755 t/t0025-auto-eol.sh\n\ndiff --git a/t/t0025-auto-eol.sh b/t/t0025-auto-eol.sh\nnew file mode 100755\nindex 0000000..5acee2d\n--- /dev/null\n+++ b/t/t0025-auto-eol.sh\n@@ -0,0 +1,180 @@\n+#!/bin/sh\n+\n+test_description='CRLF conversion'\n+\n+. ./test-lib.sh\n+\n+has_cr() {\n+\ttr '\\015' Q <\"$1\" | grep Q >/dev/null\n+}\n+\n+test_expect_success setup '\n+\n+\tgit config core.autocrlf false &&\n+\n+\tfor w in Hello world how are you; do echo $w; done >one &&\n+\tfor w in I am very very fine thank you; do echo ${w}Q; done | q_to_cr >two &&\n+\tgit add . &&\n+\n+\tgit commit -m initial &&\n+\n+\tone=`git rev-parse HEAD:one` &&\n+\ttwo=`git rev-parse HEAD:two` &&\n+\n+\tfor w in Some extra lines here; do echo $w; done >>one &&\n+\tgit diff >patch.file &&\n+\tpatched=`git hash-object --stdin autocrlf=true' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle crlf &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_expect_failure 'auto-eol=true, eolStyle=lf <=> autocrlf=input' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle lf &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -n \"$twodiff\"\n+'\n+\n+test_expect_success 'auto-eol=true, eolStyle=false <=> autocrlf=false' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf false &&\n+\tgit config core.eolstyle false &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -z \"$twodiff\"\n+'\n+\n+test_expect_success 'autocrlf=true overrides auto-eol=true, eolStyle=lf' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\tgit config core.eolstyle lf &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_expect_success 'autocrlf=input overrides auto-eol=true, eolStyle=crlf' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf input &&\n+\tgit config core.eolstyle crlf &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\n+\tif has_cr one || ! has_cr two\n+\tthen\n+\t\techo \"Eh? $f\"\n+\t\tfalse\n+\tfi &&\n+\tonediff=`git diff one` &&\n+\ttwodiff=`git diff two` &&\n+\ttest -z \"$onediff\" -a -n \"$twodiff\"\n+'\n+\n+test_expect_success 'autocrlf=true overrides auto-eol=true, eolStyle=false' '\n+\n+\trm -f .gitattributes tmp one two &&\n+\tgit config core.autocrlf true &&\n+\tgit config core.eolstyle false &&\n+\techo \"* auto-eol\" > .gitattributes &&\n+\tgit read-tree --reset -u HEAD &&\n+\tunset missing_cr &&\n+\n+\tfor f in one two\n+\tdo\n+\t\tif ! has_cr \"$f\"\n+\t\tthen\n+\t\t\techo \"Eh? $f\"\n+\t\t\tmissing_cr=1\n+\t\t\tbreak\n+\t\tfi\n+\tdone &&\n+\ttest -z \"$missing_cr\"\n+'\n+\n+test_done\n-- \n1.7.1.3.gb95c9\n"},{"id":"141094","messageId":"97a8241cefd924a56bfb22315844e9dc0e0de21a.1273183206.git.eyvind.bernhardsen@gmail.com","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"[PATCH/RFC 3/3] Add per-repository eol normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-06T22:27:35Z","receivedAt":"2010-05-06T22:27:35Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"Implement an alternative end-of-line conversion setting which uses a new\nattribute, \"auto-eol\", and a new config variable, \"core.eolStyle\" to\nenable end-of-line conversion.\n\nThe auto-eol attribute enables automatic line ending detection and\nconversion for files on which it is set. Since attributes are under\nversion control, this setting is copied when the repository is cloned.\nIt can also be changed over the history of a repository, with some\ncaveats.\n\nThe core.eolStyle variable is used to decide if LF or CRLF line endings\nare preferred in the working directory. It is only used when auto-eol\nis set, and defaults to the platform-native line ending.\n\n\"core.autocrlf\" overrides auto-eol when set to anything but \"false\".\n\nSigned-off-by: Eyvind Bernhardsen \n---\n Documentation/config.txt | 11 ++++-\n Documentation/gitattributes.txt | 92 +++++++++++++++++++++++++++++++++------\n convert.c | 48 ++++++++++++++------\n t/t0025-auto-eol.sh | 4 +-\n 4 files changed, 123 insertions(+), 32 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 92f851e..7bbf8a0 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -207,9 +207,16 @@ core.autocrlf::\n \tthe file's `crlf` attribute, or if `crlf` is unspecified,\n \tbased on the file's contents. See linkgit:gitattributes[5].\n \n+core.eolStyle::\n+\tSets the line ending type to use for text files in the working\n+\tdirectory when the `auto-eol` property is set. Alternatives are\n+\t'lf', 'crlf', 'native' and 'false'. 'native', the default, uses\n+\tthe platform's native line ending. 'false' disables `auto-eol`\n+\tline ending conversion. See linkgit:gitattributes[5].\n+\n core.safecrlf::\n-\tIf true, makes git check if converting `CRLF` as controlled by\n-\t`core.autocrlf` is reversible. Git will verify if a command\n+\tIf true, makes git check if converting `CRLF` is reversible when\n+\tend-of-line conversion is active. Git will verify if a command\n \tmodifies a file in the work tree either directly or indirectly.\n \tFor example, committing a file followed by checking out the\n \tsame file should yield the original file in the work tree. If\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex d892e64..1c52ae9 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -92,6 +92,46 @@ such as 'git checkout' and 'git merge' run. They also affect how\n git stores the contents you prepare in the working tree in the\n repository upon 'git add' and 'git commit'.\n \n+`auto-eol`\n+^^^^^^^^^^\n+\n+This attribute enables automatic end-of-line conversion (see below).\n+When `auto-eol` is used, it should in most cases be set for all files in\n+the repository.\n+\n+Set::\n+\n+\tSetting the `auto-eol` attribute turns on automatic\n+\tconversion of line endings. When `auto-eol` is set,\n+\tline endings are converted to LF on checkin, and if\n+\t`core.eolStyle` is set to \"crlf\", line endings are\n+\talso converted to CRLF on checkout.\n+\n+Unset::\n+\n+\tNo line-ending conversion is performed.\n+\n+NOTE: When committing a change that sets this attribute in an existing\n+repository, line endings should be normalized as part of the same\n+commit. From a clean working directory:\n+\n+-------------------------------------------------\n+$ echo \"* auto-eol\" >.gitattributes\n+$ rm .git/index # Remove the index to force git to\n+$ git reset # re-scan the working directory\n+$ git status # Show files that will be normalized\n+$ git add -u\n+$ git add .gitattributes\n+$ git commit -m \"Introduce end-of-line normalization\"\n+-------------------------------------------------\n+\n+If any files that should not be normalized show up in 'git status',\n+unset their `crlf` attribute in `.gitattributes` before 'git add -u'.\n+\n+`core.autocrlf` overrides `auto-eol` if set to \"true\" or \"input\".\n+Setting `core.eolStyle` to \"false\" prevents line ending conversion even\n+when `auto-eol` is set.\n+\n `crlf`\n ^^^^^^\n \n@@ -100,7 +140,7 @@ This attribute controls the line-ending convention.\n Set::\n \n \tSetting the `crlf` attribute on a path is meant to mark\n-\tthe path as a \"text\" file. 'core.autocrlf' conversion\n+\tthe path as a \"text\" file. End-of-line conversion\n \ttakes place without guessing the content type by\n \tinspection.\n \n@@ -111,8 +151,8 @@ Unset::\n \n Unspecified::\n \n-\tUnspecified `crlf` attribute tells git to apply the\n-\t`core.autocrlf` conversion when the file content looks\n+\tUnspecified `crlf` attribute tells git to apply\n+\tend-of-line conversion when the file content looks\n \tlike text.\n \n Set to string value \"input\"::\n@@ -125,20 +165,44 @@ Any other value set to `crlf` attribute is ignored and git acts\n as if the attribute is left unspecified.\n \n \n-The `core.autocrlf` conversion\n-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n-\n-If the configuration variable `core.autocrlf` is false, no\n-conversion is done.\n-\n-When `core.autocrlf` is true, it means that the platform wants\n-CRLF line endings for files in the working tree, and you want to\n-convert them back to the normal LF line endings when checking\n-in to the repository.\n+End-of-line conversion\n+^^^^^^^^^^^^^^^^^^^^^^\n \n-When `core.autocrlf` is set to \"input\", line endings are\n-converted to LF upon checkin, but there is no conversion done\n-upon checkout.\n+While git normally leaves file contents alone, it can be configured to\n+normalize line endings to LF in the repository and, optionally, to\n+convert them to CRLF when files are checked out. Binary files are\n+detected automatically and will not be modified; this detection can be\n+overridden with the `crlf` attribute.\n+\n+NOTE: This conversion requires the repository to be free of text files\n+containing CRLFs. When it is enabled on an existing repository, the\n+index should be rebuilt to find any such files, and these files should\n+either have their `crlf` attribute set to false (\"-crlf\"), or they\n+should be checked in to the repository in normalized form.\n+\n+End-of-line conversion is controlled by the configuration variables\n+`core.eolStyle` and `core.autocrlf` and the attributes `auto-eol` and\n+`crlf`.\n+\n+When a repository is shared between users on platforms with different\n+end-of-line conventions, using the `auto-eol` mechanism is probably the\n+best choice. A developer on a minority platform sharing a repository\n+with a large group of users on an LF-native platform would want to set\n+`core.autocrlf` instead.\n+\n+End-of-line conversion is enabled as follows:\n+\n+- If the attribute `auto-eol` is not set and the configuration variable\n+ `core.autocrlf` is false, no conversion is done.\n+\n+- When the `auto-eol` attribute is set, or `core.autocrlf` is true or\n+ \"input\", line endings are normalized as files are checked in to the\n+ repository.\n+\n+- When the `auto-eol` attribute is set and `core.eolStyle` is \"crlf\", or\n+ `core.autocrlf` is true, line endings in the repository are normalized\n+ and will be converted to CRLF when files are checked out to the\n+ working tree.\n \n If `core.safecrlf` is set to \"true\" or \"warn\", git verifies if\n the conversion is reversible for the current setting of\ndiff --git a/convert.c b/convert.c\nindex 4f8fcb7..f0f59e3 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -90,12 +90,13 @@ static int is_binary(unsigned long size, struct text_stat *stats)\n }\n \n static void check_safe_crlf(const char *path, int action,\n- struct text_stat *stats, enum safe_crlf checksafe)\n+\t\t\t struct text_stat *stats, enum safe_crlf checksafe,\n+\t\t\t int eol_conversion)\n {\n \tif (!checksafe)\n \t\treturn;\n \n-\tif (action == CRLF_INPUT || auto_crlf <= 0) {\n+\tif (action == CRLF_INPUT || eol_conversion <= 0) {\n \t\t/*\n \t\t * CRLFs would not be restored by checkout:\n \t\t * check if we'd remove CRLFs\n@@ -106,7 +107,7 @@ static void check_safe_crlf(const char *path, int action,\n \t\t\telse /* i.e. SAFE_CRLF_FAIL */\n \t\t\t\tdie(\"CRLF would be replaced by LF in %s.\", path);\n \t\t}\n-\t} else if (auto_crlf > 0) {\n+\t} else if (eol_conversion > 0) {\n \t\t/*\n \t\t * CRLFs would be added by checkout:\n \t\t * check if we have \"naked\" LFs\n@@ -121,12 +122,13 @@ static void check_safe_crlf(const char *path, int action,\n }\n \n static int crlf_to_git(const char *path, const char *src, size_t len,\n- struct strbuf *buf, int action, enum safe_crlf checksafe)\n+\t\t struct strbuf *buf, int action, enum safe_crlf checksafe,\n+\t\t int eol_conversion)\n {\n \tstruct text_stat stats;\n \tchar *dst;\n \n-\tif ((action == CRLF_BINARY) || !auto_crlf || !len)\n+\tif ((action == CRLF_BINARY) || !eol_conversion || !len)\n \t\treturn 0;\n \n \tgather_stats(src, len, &stats);\n@@ -147,7 +149,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n \t\t\treturn 0;\n \t}\n \n-\tcheck_safe_crlf(path, action, &stats, checksafe);\n+\tcheck_safe_crlf(path, action, &stats, checksafe, eol_conversion);\n \n \t/* Optimization: No CR? Nothing to convert, regardless. */\n \tif (!stats.cr)\n@@ -180,13 +182,13 @@ static int crlf_to_git(const char *path, const char *src, size_t len,\n }\n \n static int crlf_to_worktree(const char *path, const char *src, size_t len,\n- struct strbuf *buf, int action)\n+\t\t\t struct strbuf *buf, int action, int eol_conversion)\n {\n \tchar *to_free = NULL;\n \tstruct text_stat stats;\n \n \tif ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||\n-\t auto_crlf <= 0)\n+\t eol_conversion <= 0)\n \t\treturn 0;\n \n \tif (!len)\n@@ -377,17 +379,31 @@ static void setup_convert_check(struct git_attr_check *check)\n \tstatic struct git_attr *attr_crlf;\n \tstatic struct git_attr *attr_ident;\n \tstatic struct git_attr *attr_filter;\n+\tstatic struct git_attr *attr_auto_eol;\n \n \tif (!attr_crlf) {\n \t\tattr_crlf = git_attr(\"crlf\");\n \t\tattr_ident = git_attr(\"ident\");\n \t\tattr_filter = git_attr(\"filter\");\n+\t\tattr_auto_eol = git_attr(\"auto-eol\");\n \t\tuser_convert_tail = &user_convert;\n \t\tgit_config(read_convert_config, NULL);\n \t}\n \tcheck[0].attr = attr_crlf;\n \tcheck[1].attr = attr_ident;\n \tcheck[2].attr = attr_filter;\n+\tcheck[3].attr = attr_auto_eol;\n+}\n+\n+static int choose_eol_conversion(int auto_eol)\n+{\n+\tif (auto_crlf)\n+\t\treturn auto_crlf;\n+\n+\tif (auto_eol)\n+\t\treturn eol_style;\n+\n+\treturn 0;\n }\n \n static int count_ident(const char *cp, unsigned long size)\n@@ -571,9 +587,9 @@ static int git_path_check_ident(const char *path, struct git_attr_check *check)\n int convert_to_git(const char *path, const char *src, size_t len,\n struct strbuf *dst, enum safe_crlf checksafe)\n {\n-\tstruct git_attr_check check[3];\n+\tstruct git_attr_check check[4];\n \tint crlf = CRLF_GUESS;\n-\tint ident = 0, ret = 0;\n+\tint ident = 0, ret = 0, auto_eol = 0;\n \tconst char *filter = NULL;\n \n \tsetup_convert_check(check);\n@@ -584,6 +600,7 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->clean)\n \t\t\tfilter = drv->clean;\n+\t\tauto_eol = git_path_check_ident(path, check + 3);\n \t}\n \n \tret |= apply_filter(path, src, len, dst, filter);\n@@ -591,7 +608,8 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n \t}\n-\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe);\n+\tret |= crlf_to_git(path, src, len, dst, crlf, checksafe,\n+\t\tchoose_eol_conversion(auto_eol));\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n@@ -601,9 +619,9 @@ int convert_to_git(const char *path, const char *src, size_t len,\n \n int convert_to_working_tree(const char *path, const char *src, size_t len, struct strbuf *dst)\n {\n-\tstruct git_attr_check check[3];\n+\tstruct git_attr_check check[4];\n \tint crlf = CRLF_GUESS;\n-\tint ident = 0, ret = 0;\n+\tint ident = 0, ret = 0, auto_eol = 0;\n \tconst char *filter = NULL;\n \n \tsetup_convert_check(check);\n@@ -614,6 +632,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \t\tdrv = git_path_check_convert(path, check + 2);\n \t\tif (drv && drv->smudge)\n \t\t\tfilter = drv->smudge;\n+\t\tauto_eol = git_path_check_ident(path, check + 3);\n \t}\n \n \tret |= ident_to_worktree(path, src, len, dst, ident);\n@@ -621,7 +640,8 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\n \t}\n-\tret |= crlf_to_worktree(path, src, len, dst, crlf);\n+\tret |= crlf_to_worktree(path, src, len, dst, crlf,\n+\t\tchoose_eol_conversion(auto_eol));\n \tif (ret) {\n \t\tsrc = dst->buf;\n \t\tlen = dst->len;\ndiff --git a/t/t0025-auto-eol.sh b/t/t0025-auto-eol.sh\nindex 5acee2d..5195885 100755\n--- a/t/t0025-auto-eol.sh\n+++ b/t/t0025-auto-eol.sh\n@@ -60,7 +60,7 @@ test_expect_success 'no auto-eol, explicit eolstyle=native causes no changes' '\n \ttest -z \"$onediff\" -a -z \"$twodiff\"\n '\n \n-test_expect_failure 'auto-eol=true, eolStyle=crlf <=> autocrlf=true' '\n+test_expect_success 'auto-eol=true, eolStyle=crlf <=> autocrlf=true' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n@@ -81,7 +81,7 @@ test_expect_failure 'auto-eol=true, eolStyle=crlf <=> autocrlf=true' '\n \ttest -z \"$missing_cr\"\n '\n \n-test_expect_failure 'auto-eol=true, eolStyle=lf <=> autocrlf=input' '\n+test_expect_success 'auto-eol=true, eolStyle=lf <=> autocrlf=input' '\n \n \trm -f .gitattributes tmp one two &&\n \tgit config core.autocrlf false &&\n-- \n1.7.1.3.gb95c9\n"},{"id":"141101","messageId":"o2v40aa078e1005061625md5fede79h660a22227c4f22d1@mail.gmail.com","threadId":"23705","inReplyTo":"w2h600158c31005061514m1fc1e75ay9096eb27d9a1a4ba@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-05-06T23:25:25Z","receivedAt":"2010-05-06T23:25:25Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, May 7, 2010 at 12:14 AM, hasen j wrote:\n>>>\n>>> When I'm on windows, I prefer LF (unless the project already uses\n>>> CRLF, or it's outside my control).\n>>>\n>>\n>> \"When I'm on windows\" leads me to believe Windows is not your primary\n>> operating system. If not, please excuse me.\n>\n> I used to be, I only moved to linux about a year ago, but I use\n> windows at work, and I started using git when I was on windows.\n>\n\nOK, I'm sorry for assuming some Windows-ignorance.\n\n>> Open source isn't the only model for developing software.\n>\n> But it's probably the most common scenario where people run into line\n> ending issues.\n>\n\nClosed source does not imply a single operating system, and you get\nthese issues whenever you have a project with targets systems with\ndifferent newline style. In my day job I develop closed source,\nmulti-platform software, using git. So it's certainly not MY most\ncommon scenario.\n\nAnd even if it were, so what? When did we start only caring for the\nmost common case?\n\n> If the project is a VS project, then it's probably not multi-platform,\n> plus everyone at the company would be using windows anyway, so there's\n> no line-ending issue.\n>\n\nUsing VS on Windows does not exclude other platforms either. Either\none can maintain multiple build-systems for Windows and Unix-y\nsystems, or one can use a system like CMake that automate the job.\n\nA typical case where you pretty much have to build using Visual Studio\nis when you develop a C++ library, where your Windows users use Visual\nStudio (due to C++' symbol-mangling you have to use the same\ncompiler). This is not an entirely uncommon situation for open source\nsoftware.\n\n>> And again... even if it were, working well together with\n>> visual studio support would be very beneficial for quite a bit of\n>> projects. Visual Studio is probably the most used code-editor among\n>> Windows-developers (with a good margin too, I suspect), so ignoring it\n>> is would just be sticking your head in the sand - or worse, asking for\n>> less contributions from Windows-users (which can often be a problem in\n>> the first place).\n>\n> The problem can be avoided with a little bit of education. VS is not a\n> multiplatform IDE anyway\n> Sure, it can't work with LF endings as well as notepad++, but it's not\n> git's responsibility to try to fix that.\n\nAgain, using VS on Windows does not exclude other platforms. I'm not\nsure what you mean with \"a little bit of education\" here, though.\n\nCRLF is Windows' native newline style. If git can't check out to that,\nit'll look like a lot less attractive solution to anybody that targets\nWindows compared to the competition. If it wasn't for core.autocrlf, I\nwould have never switched myself.\n\n>\n> I just don't think it's a big enough issue to be built into git.\n>\n> IMHO it's much better to work around the problem (if and when it\n> arises) by using clean and smudge filters in .gitattributes, than\n> having it built in and enabled by default in the msysgit installer.\n>\n\nBut it IS built in. And it's very unlikely that this feature will ever\nbe removed. So what's the problem with using it?\n\nAnd it's a very common thing to want to do, so why make everybody who\ndoes have to jump through hoops just because YOU don't need it?\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"141102","messageId":"g2m32541b131005061638o8a5e3490x8a5b1c3eb8c73c70@mail.gmail.com","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-06T23:38:22Z","receivedAt":"2010-05-06T23:38:22Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 6, 2010 at 6:27 PM, Eyvind Bernhardsen\n wrote:\n> - An attribute called \"auto-eol\" is set in the repository to turn on\n>  normalization of line endings.  Since attributes are content, the\n>  setting is copied when the repository is cloned and can be changed in\n>  an existing repository (with a few caveats).  Setting this attribute\n>  is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n>\n> - A configuration variable called \"core.eolStyle\" determines which type\n>  of line endings are used when checking files out to the working\n>  directory.\n\nI definitely like this. The existing core.autocrlf setting does cause\na lot of confusion for precisely the reason you stated: people often\nforget to set it until *after* they've checked out the repo, at which\ntime all the files are already checked out wrong and total confusion\nensues.\n\nBeing able to globally set my preferred eol style in one place, but\nonly have it take effect on projects (and individual files in that\nproject) that we already know have eol constraints, would be\nwonderful.\n\nOf course this new feature would be in addition to the existing\ncore.autocrlf setting, not replacing it.\n\nThis would definitely help our Windows users at work.\n\nHave fun,\n\nAvery\n"},{"id":"141103","messageId":"z2k32541b131005061654je98055aanac16e790d412684e@mail.gmail.com","threadId":"23705","inReplyTo":"g2m32541b131005061638o8a5e3490x8a5b1c3eb8c73c70@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-06T23:54:30Z","receivedAt":"2010-05-06T23:54:30Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 6, 2010 at 7:38 PM, Avery Pennarun wrote:\n> I definitely like this.  The existing core.autocrlf setting does cause\n> a lot of confusion for precisely the reason you stated: people often\n> forget to set it until *after* they've checked out the repo, at which\n> time all the files are already checked out wrong and total confusion\n> ensues.\n\nOh, just to clarify the rationale a bit more:\n\nWhether a developer wants autocrlf or not actually is\nproject-dependent, not user-dependent or \"all Windows users want\nautocrlf.\" For example, if I'm running Cygwin and I checkout a copy\nof the git source code to build with Cygwin gcc, I definitely don't\nwant autocrlf. (Actually, almost always, for C source code I don't\nwant autocrlf, or I want autocrlf=input.)\n\nIf I'm checking out a copy of our Delphi project on Windows, though, I\nneed autocrlf or the IDE goes bananas. And our team would be happy to\nput the right magic incantation in a .gitattributes file in our Delphi\nproject if it would make this work out automatically.\n\nSetting core.autocrlf on one of our Windows developers' systems can't\ncover both of those cases automatically, whereas the settings Eyvind\nhas proposed would solve our problem.\n\nHave fun,\n\nAvery\n"},{"id":"141116","messageId":"hs0enf$vij$1@dough.gmane.org","threadId":"23705","inReplyTo":"4BE141E3.2060904@gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Gelonida","fromEmail":"gelonida@gmail.com","sentAt":"2010-05-07T07:15:59Z","receivedAt":"2010-05-07T07:15:59Z","isPatch":false,"sender":{"key":"gelonida@gmail.com","avatar":null},"body":"I'm not convinced, that one policy is a good solution, but it really\ndepends on your project.\n\n\nWhat we do:\n.bat files with windows line endings\n.cmd .vbs files with windows line endings\n.sh files with unix file endings\n source files (.c .h .py .pl) with unix file endings\n.txt files with unix file endings\n\nThe rest untouched:\nyou might add a precommti hook to verify this.\nSO war we din't bother to automate it, but I must admint, that we had\noccasional rare jickups.\n\n\nbye\n\n\nN\n\n\nmat wrote:\n> Hi\n> \n> I have two git projects:\n> -one (A) with linux people only\n> -one (B) with someone using windows\n> \n> As we had \"end of line\" problems with the person using windows (B), I used:\n> \n> git config --global core.autocrlf true\n> \n> Following advices from:\n> http://help.github.com/dealing-with-lineendings/\n> \n> So everything now if fine with project B, but now some problems using\n> project (A): I wanted to copy the whole project file to another dir, and\n> now it is complaining about the change, signaling warning:\n> \n> CRLF will be replaced by LF in .../A.\n> \n> So I don't know exactly what I should do...Should I change all the CRLF\n> from project A, but people will have also problems, or can I switch the\n> config, once I'm using project A and B? It is not so clear in my mind\n> and I would appreciate any advice!!\n> \n> Thanks a lot\n> \n> Matthieu Stigler\n> \n> \n> \n"},{"id":"141119","messageId":"s2v40aa078e1005070145p8e294a80l6013f3011a6199f0@mail.gmail.com","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-05-07T08:45:36Z","receivedAt":"2010-05-07T08:45:36Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, May 7, 2010 at 12:27 AM, Eyvind Bernhardsen\n wrote:\n> This discussion couldn't be more timely, as I've recently acquired a\n> desperate need to solve CRLF problems at $dayjob.  This patch series\n> introduces a new way of turning on autocrlf normalization by splitting\n> the configuration into two:\n>\n> - An attribute called \"auto-eol\" is set in the repository to turn on\n>  normalization of line endings.  Since attributes are content, the\n>  setting is copied when the repository is cloned and can be changed in\n>  an existing repository (with a few caveats).  Setting this attribute\n>  is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n>\n> - A configuration variable called \"core.eolStyle\" determines which type\n>  of line endings are used when checking files out to the working\n>  directory.\n>\n\nBeautiful! This approach addresses most (all?) issues I've had with\ncore.autocrlf in a very elegant way IMO! :)\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"141127","messageId":"7v4oijhdsi.fsf@alter.siamese.dyndns.org","threadId":"23705","inReplyTo":"cover.1273183206.git.eyvind.bernhardsen@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-07T16:33:49Z","receivedAt":"2010-05-07T16:33:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eyvind Bernhardsen writes:\n\n> - An attribute called \"auto-eol\" is set in the repository to turn on\n> normalization of line endings. Since attributes are content, the\n> setting is copied when the repository is cloned and can be changed in\n> an existing repository (with a few caveats). Setting this attribute\n> is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n\nIn what way is this attribute different from existing \"crlf\" attribute?\n\nIt feels as if this series is fixing shortcomings of the combination of\ncore.autocrlf configuration and crlf attribute while trying very hard to\nkeep their shortcomings when the user doesn't say so. What is the\ndownside of making the existing \"core.autocrlf\" + \"crlf\" combination do\nwhat your patch wanted to do without retaining this \"keep the existing\nshortcomings for backward compatibility\"?\n\n> 1. Setting core.autocrlf in your global or system configuration is a\n> pain\n\nThis is a wrong thing to do to begin with, and not worth discussing. You\nknow and your readers know that line ending convention in the repository\ndata (i.e. blobs) is under project control while line ending convention in\nthe working tree is end user preference.\n\n> 2. Setting core.autocrlf in an individual repository would be okay\n> except that naive users will do it after they have already cloned:\n> unless core.autocrlf is set globally, the clone will have the wrong line\n> endings, and the user needs to know how to refresh it manually (rm -rf *\n> && git checkout -f).\n\nThis may be a worthy goal. But if a \"auto-eol\" attribute \"fixes\" this,\nperhaps \"crlf\" attribute can be taught to fix it the same way, no?\n"},{"id":"141132","messageId":"v2q32541b131005070957j819890dbqe613985ff5f65b84@mail.gmail.com","threadId":"23705","inReplyTo":"7v4oijhdsi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T16:57:12Z","receivedAt":"2010-05-07T16:57:12Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 12:33 PM, Junio C Hamano wrote:\n> Eyvind Bernhardsen writes:\n>> - An attribute called \"auto-eol\" is set in the repository to turn on\n>>   normalization of line endings.  Since attributes are content, the\n>>   setting is copied when the repository is cloned and can be changed in\n>>   an existing repository (with a few caveats).  Setting this attribute\n>>   is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n>\n> In what way is this attribute different from existing \"crlf\" attribute?\n\nMostly that it relates to the new core.eolStyle config option instead\nof core.autocrlf. Arguably you could use the same gitattribute to set\nboth config options, but I don't know how you'd make that respond in a\nsane backwards-compatible fashion.\n\n> It feels as if this series is fixing shortcomings of the combination of\n> core.autocrlf configuration and crlf attribute while trying very hard to\n> keep their shortcomings when the user doesn't say so.  What is the\n> downside of making the existing \"core.autocrlf\" + \"crlf\" combination do\n> what your patch wanted to do without retaining this \"keep the existing\n> shortcomings for backward compatibility\"?\n\nIs this even possible? If core.autocrlf is set, then files all over\nthe place start getting crlf conversion, even if no attributes are set\nat all. If core.eolStyle is set, only files with the auto-eol\nattribute set appropriately will experience any conversion.\n\nMaybe the options aren't named ideally. \"core.eolStyle\" might better\nbe named \"core.nativeEol\" - it tells git what the native EOL style is\non your computer / in this repository, but it doesn't tell git to *do*\nanything with this information. The problem with core.autocrlf is\nthat it mixes two concepts: identifying your native EOL style, and\ntelling git to do stuff. The existing gitattribute can then tell git\n*not* to do stuff, but almost no projects have a .gitattributes file\nthat does this.\n\n>> 1. Setting core.autocrlf in your global or system configuration is a\n>> pain\n>\n> This is a wrong thing to do to begin with, and not worth discussing.\n\nHa, doesn't msysgit do this by default? It did at one point, anyway.\nI use cygwin git (which doesn't because it thinks it's Unix) so I\ndon't know.\n\nIf this was ever the default behaviour, then it's at least not\n*obviously* wrong.\n\nThe end result is that nobody really likes the current autocrlf\nbehaviour, though, so I'd agree that it *ends up* being wrong. Just\nas setting it on a per-checkout basis also ends up being wrong,\nbecause it's so easy to forget.\n\n> You\n> know and your readers know that line ending convention in the repository\n> data (i.e. blobs) is under project control while line ending convention in\n> the working tree is end user preference.\n\nYes. But the current system doesn't make it very easy to state your preference.\n\n>> 2. Setting core.autocrlf in an individual repository would be okay\n>> except that naive users will do it after they have already cloned:\n>> unless core.autocrlf is set globally, the clone will have the wrong line\n>> endings, and the user needs to know how to refresh it manually (rm -rf *\n>> && git checkout -f).\n>\n> This may be a worthy goal.  But if a \"auto-eol\" attribute \"fixes\" this,\n> perhaps \"crlf\" attribute can be taught to fix it the same way, no?\n\nIt fixes it by making the global setting actually do what people want.\n I'm not sure the existing config option can be made to work like\nthat.\n\nAgain, maybe it would make sense to combine a single attribute but\nhave two config options (and people can eventually just stop using\ncore.autocrlf altogether). I suspect it might subtly break some\nexisting projects, though.\n\nHave fun,\n\nAvery\n"},{"id":"141133","messageId":"alpine.LFD.2.00.1005071007320.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"7v4oijhdsi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T17:10:09Z","receivedAt":"2010-05-07T17:10:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Junio C Hamano wrote:\n\n> Eyvind Bernhardsen writes:\n> \n> > - An attribute called \"auto-eol\" is set in the repository to turn on\n> > normalization of line endings. Since attributes are content, the\n> > setting is copied when the repository is cloned and can be changed in\n> > an existing repository (with a few caveats). Setting this attribute\n> > is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n> \n> In what way is this attribute different from existing \"crlf\" attribute?\n\nThe existing crlf attribute is a no-op _unless_ core.autocrlf is set, \nisn't it?\n\nThe whole point of Eyvind's series is to be able to set crlf attributes \nwithout having to set the config option - because he wants to make sure \nthat a new clone always gets the proper crlf handling without users \nhaving to do anything extra.\n\nAnd I do have to say that it makes sense.\n\nI also do think that maybe we could just change the existing crlf \nattribute to work even without 'core.autocrlf'. \n\n\t\t\tLinus\n"},{"id":"141142","messageId":"alpine.LFD.2.00.1005071147460.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071007320.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T19:02:48Z","receivedAt":"2010-05-07T19:02:48Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Linus Torvalds wrote:\n> \n> I also do think that maybe we could just change the existing crlf \n> attribute to work even without 'core.autocrlf'. \n\nBtw, another option might be to start searching \".gitconfig\", but only \nallow a certain \"safe subset\" of config options in that. Things that can \nreally be about the project itself, and not per-user or per-repository.\n\nAnd parse it before ~/.gitconfig and .git/config, so that people can \nalways override it.\n\nI dunno. Looking at the config options, there really aren't a lot of them \nthat make sense on a project scale. There's a few, though. Things like\n\n\tcore.autocrlf\n\ti18n.commitEnconfig\n\nand possibly others..\n\n\t\tLinus\n"},{"id":"141143","messageId":"7vzl0bfs5n.fsf@alter.siamese.dyndns.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071007320.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-07T19:06:28Z","receivedAt":"2010-05-07T19:06:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 7 May 2010, Junio C Hamano wrote:\n>\n>> Eyvind Bernhardsen writes:\n>> \n>> > - An attribute called \"auto-eol\" is set in the repository to turn on\n>> > normalization of line endings. Since attributes are content, the\n>> > setting is copied when the repository is cloned and can be changed in\n>> > an existing repository (with a few caveats). Setting this attribute\n>> > is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n>> \n>> In what way is this attribute different from existing \"crlf\" attribute?\n>\n> The existing crlf attribute is a no-op _unless_ core.autocrlf is set, \n> isn't it?\n>\n> The whole point of Eyvind's series is to be able to set crlf attributes \n> without having to set the config option - because he wants to make sure \n> that a new clone always gets the proper crlf handling without users \n> having to do anything extra.\n>\n> And I do have to say that it makes sense.\n>\n> I also do think that maybe we could just change the existing crlf \n> attribute to work even without 'core.autocrlf'. \n\nYes, that is exactly what I was alluding to.\n"},{"id":"141145","messageId":"n2k32541b131005071211sb2411334v4f0919abfeb4cbb7@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071147460.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T19:11:21Z","receivedAt":"2010-05-07T19:11:21Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 3:02 PM, Linus Torvalds\n wrote:\n> Btw, another option might be to start searching \".gitconfig\", but only\n> allow a certain \"safe subset\" of config options in that. Things that can\n> really be about the project itself, and not per-user or per-repository.\n> [...]\n> Things like\n>\n>        core.autocrlf\n>        i18n.commitEnconfig\n\nUnfortunately this option wouldn't be as flexible as Eyvind's current proposal.\n\nWhat his method allows is to mark some files in a project as \"these\nshould be the native EOL style\" and others as \"these should be left\nalone.\" Then each person can set a (usually global) config option\nthat states what the native EOL style should be. Like core.autocrlf,\nonly it wouldn't affect projects without crlf attributes (like git.git\nor linux.git) where CRLF translation is pretty much always wrong.\n(And if one person disagrees that it's always wrong, well, he can\nalways set core.autocrlf for himeself.)\n\nHave fun,\n\nAvery\n"},{"id":"141146","messageId":"alpine.LFD.2.00.1005071213550.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"n2k32541b131005071211sb2411334v4f0919abfeb4cbb7@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T19:16:00Z","receivedAt":"2010-05-07T19:16:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Avery Pennarun wrote:\n> \n> Unfortunately this option wouldn't be as flexible as Eyvind's current proposal.\n\nOh, absolutely it is.\n\n> What his method allows is to mark some files in a project as \"these\n> should be the native EOL style\" and others as \"these should be left\n> alone.\"\n\nBut that's what a .gitconfig would too. We _already_ have that \n.gitattribute thing to then distinguish particular pathname rules. It's \njust that currently .git/config is needed to _enable_ it.\n\n\t\t\tLinus\n"},{"id":"141147","messageId":"D735B346-968F-4AAE-8990-27ECCCA812AF@gmail.com","threadId":"23705","inReplyTo":"n2k32541b131005071211sb2411334v4f0919abfeb4cbb7@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-07T19:23:47Z","receivedAt":"2010-05-07T19:23:47Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 7. mai 2010, at 21.11, Avery Pennarun wrote:\n\n> On Fri, May 7, 2010 at 3:02 PM, Linus Torvalds\n> wrote:\n>> Btw, another option might be to start searching \".gitconfig\", but only\n>> allow a certain \"safe subset\" of config options in that. Things that can\n>> really be about the project itself, and not per-user or per-repository.\n>> [...]\n>> Things like\n>> \n>> core.autocrlf\n>> i18n.commitEnconfig\n> \n> Unfortunately this option wouldn't be as flexible as Eyvind's current proposal.\n\nThanks for the support!\n\nMy objection to this idea is more practical: I suspect that parsing .gitconfig from the repository would be a lot more work than my simple hack :)\n-- \nEyvind\n"},{"id":"141148","messageId":"B929B102-3175-4CB2-AEEB-131E3F96DC94@gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071007320.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-07T19:25:13Z","receivedAt":"2010-05-07T19:25:13Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 7. mai 2010, at 19.10, Linus Torvalds wrote:\n\n> I also do think that maybe we could just change the existing crlf \n> attribute to work even without 'core.autocrlf'. \n\nAh, of course. Thanks for the clarification! I didn't understand what Junio meant (and was composing a long email which may or may not have had a bitter tone); now I'm preparing a new patch series instead.\n-- \nEyvind\n"},{"id":"141149","messageId":"alpine.LFD.2.00.1005071529050.14468@xanadu.home","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071147460.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-05-07T19:31:58Z","receivedAt":"2010-05-07T19:31:58Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 7 May 2010, Linus Torvalds wrote:\n\n> Btw, another option might be to start searching \".gitconfig\", but only \n> allow a certain \"safe subset\" of config options in that. Things that can \n> really be about the project itself, and not per-user or per-repository.\n> \n> And parse it before ~/.gitconfig and .git/config, so that people can \n> always override it.\n> \n> I dunno. Looking at the config options, there really aren't a lot of them \n> that make sense on a project scale. There's a few, though. Things like\n> \n> \tcore.autocrlf\n> \ti18n.commitEnconfig\n> \n> and possibly others..\n\nGiven that only a subset of gitconfig could make sense to have \ndistributed, I think the file should be named .gitparams to make the \ndistinction clear.\n\n\nNicolas\n"},{"id":"141150","messageId":"i2i32541b131005071235z64c9de56w29a2d555cf801c9a@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071213550.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T19:35:43Z","receivedAt":"2010-05-07T19:35:43Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 3:16 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> Unfortunately this option wouldn't be as flexible as Eyvind's current proposal.\n>\n> Oh, absolutely it is.\n>\n>> What his method allows is to mark some files in a project as \"these\n>> should be the native EOL style\" and others as \"these should be left\n>> alone.\"\n>\n> But that's what a .gitconfig would too. We _already_ have that\n> .gitattribute thing to then distinguish particular pathname rules. It's\n> just that currently .git/config is needed to _enable_ it.\n\nHmm, I don't think we're saying the same thing. There are two\nseparate settings here:\n\n1) Whether a project has files that should be EOL-converted\nautomatically (we seem to all agree that this is set in\n.gitattributes, whichever attribute is used).\n\n2) Whether a particular person wants those particular files to be\nEOL-converted, and what to convert them to.\n\nThe existing semantics of core.autocrlf just don't let you express #2\nin a useful way. If I set --global core.autocrlf, it turns it on for\n*all* projects, not just ones with the .gitattribute set. If a\nproject has a .gitconfig inside that sets core.autocrlf, then it's\nreally just redundant with #1. If I set .git/config on a particular\nproject, it works, but it's far too easy to forget (and there seems to\nbe no way to set this per-project at clone time, and setting it\n*after* cloning causes git's index to get confused).\n\nEyvind's proposal is deceptively simple because it simply makes it\nmuch less error prone for users to express something that's already\n*technically* possible, but in practice, is very very frequently done\nwrong.\n\nAvery\n"},{"id":"141151","messageId":"m2g32541b131005071236u962d2c73n85d25093d1e048bb@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071529050.14468@xanadu.home","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T19:36:45Z","receivedAt":"2010-05-07T19:36:45Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 3:31 PM, Nicolas Pitre wrote:\n> On Fri, 7 May 2010, Linus Torvalds wrote:\n>> Btw, another option might be to start searching \".gitconfig\", but only\n>> allow a certain \"safe subset\" of config options in that. Things that can\n>> really be about the project itself, and not per-user or per-repository.\n>>\n>> And parse it before ~/.gitconfig and .git/config, so that people can\n>> always override it.\n>>\n>> I dunno. Looking at the config options, there really aren't a lot of them\n>> that make sense on a project scale. There's a few, though. Things like\n>>\n>>       core.autocrlf\n>>       i18n.commitEnconfig\n>>\n>> and possibly others..\n>\n> Given that only a subset of gitconfig could make sense to have\n> distributed, I think the file should be named .gitparams to make the\n> distinction clear.\n\nSince the options it *does* have are exactly the same as .git/config,\nhowever, naming it .gitconfig makes sense. I'd say just print a\nwarning when reading options that are going to be ignored for security\nreasons (or because they're not known at all, or whatever).\n\nAvery\n"},{"id":"141159","messageId":"alpine.LFD.2.00.1005071235070.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071529050.14468@xanadu.home","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T19:40:22Z","receivedAt":"2010-05-07T19:40:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Nicolas Pitre wrote:\n> \n> Given that only a subset of gitconfig could make sense to have \n> distributed, I think the file should be named .gitparams to make the \n> distinction clear.\n\nI went through the options listed in \"man gitconfig\", and quite frankly, I \ndidn't find any new ones. I didn't grep the source, and I'm sure they're \nnot all documented, but if it really is just two options, I doubt it's \nworth it at all.\n\nHopefully nobody sane uses any non-utf8 encoding for commit messages \nanyway (but what do I know - I have no idea about Asian usage, where it \nmay make more sense than in US/Western Europe). So i18n.commitEnconfig is \nnot likely to be a big deal.\n\nAnd just making the crlf attribute work regardless of core.autocrlf sounds \nlike it wouldn't be a bad idea. Just _maybe_ we could actually make an \n_explicit_ \"core.autocrlf = off/false\" actually disable any .gitattribute \ncrlf settings, but I'm not sure even that is a good idea.\n\nSo I'd suggest relegating \"core.autocrlf\" to just files that are _not_ \ncovered by some explicit .gitattribute setting. After all, that just more \nsolidly puts the \"auto\" in autocrlf.\n\n\t\tLinus\n"},{"id":"141165","messageId":"20100507194140.GC7963@pvv.org","threadId":"23705","inReplyTo":"7v4oijhdsi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2010-05-07T19:41:40Z","receivedAt":"2010-05-07T19:41:40Z","isPatch":true,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Fri, May 07, 2010 at 09:33:49AM -0700, Junio C Hamano wrote:\n> Eyvind Bernhardsen writes:\n> \n> > - An attribute called \"auto-eol\" is set in the repository to turn on\n> > normalization of line endings. Since attributes are content, the\n> > setting is copied when the repository is cloned and can be changed in\n> > an existing repository (with a few caveats). Setting this attribute\n> > is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n> \n> In what way is this attribute different from existing \"crlf\" attribute?\n\nThe crlf attribute says whether to enable autocrlf functionality for a\nfile, but that is not what is really wanted. auto-eol instead says how\nline endings should be stored in the repository. Also, auto-eol will\nonly affect files auto-detected as text (or forced to be treated as\ntext by the crlf attribute) it seems.\n\n> This may be a worthy goal. But if a \"auto-eol\" attribute \"fixes\"\n> this, perhaps \"crlf\" attribute can be taught to fix it the same way,\n> no?\n\nMaybe it is sufficient to add a new value to \"crlf\" that means:\n\n- If the file is autodetected as text:\n - Convert to LF only on commit, and\n - Convert to your preferred EOL style on checkout.\n\nI don't think autocrlf is a good place to specify preferred EOL\nstyle, it is too dangerous to set autocrlf to true by default, but it should\nnot be dangerous to say that your preferred EOL style is CRLF.\n\n- Finn Arne\n"},{"id":"141160","messageId":"alpine.LFD.2.00.1005071240590.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"i2i32541b131005071235z64c9de56w29a2d555cf801c9a@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T19:45:00Z","receivedAt":"2010-05-07T19:45:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Avery Pennarun wrote:\n> \n> 1) Whether a project has files that should be EOL-converted\n> automatically (we seem to all agree that this is set in\n> .gitattributes, whichever attribute is used).\n> \n> 2) Whether a particular person wants those particular files to be\n> EOL-converted, and what to convert them to.\n\nSo? If we were to have a .gitconfig file, then both of those things would \njust work. It's no different from Eyvind's patch, except the exact details \non syntax (and which file to set) would differ slightly.\n\nSo it's a syntactic difference, nothing more.\n\nThat said, I don't think the extra .gitconfig is even worth it, the same \nway I do _not_ think Eyvind's extra .gitattributes things are worth it. We \nalready have perfectly good .gitattributes, and the only real issue is \nthat they just don't take effect in some situations where people would \n_want_ them to take effect.\n\nSo just a small semantic change to how .gitattributes crlf works would \nlikely make everybody happy.\n\nThe only downside is that it _is_ a semantic change. It really would \nchange existing git behavior. Now, I think most people would consider the \nchange in behavior to be a clear improvement, but hey...\n\n\t\t\tLinus\n"},{"id":"141164","messageId":"g2s32541b131005071258s92e058bakc8f3a4df1e1dc634@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071240590.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T19:58:12Z","receivedAt":"2010-05-07T19:58:12Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 3:45 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> 1) Whether a project has files that should be EOL-converted\n>> automatically (we seem to all agree that this is set in\n>> .gitattributes, whichever attribute is used).\n>>\n>> 2) Whether a particular person wants those particular files to be\n>> EOL-converted, and what to convert them to.\n>\n> So? If we were to have a .gitconfig file, then both of those things would\n> just work.\n\nNo! The whole point is that each user *does* still want to be able to\ndecide how to convert the files tagged by the crlf gitattribute (or a\nnew attribute, I don't care). Setting this in a .gitconfig file\ninside the project is pointless; I need it in my *personal* config.\nmsysgit users want to set it globally to CRLF by default, Linux or\ncygwin users probably want to set it to LF by default.\n\nSo #1 is useful to have in the repo, #2 is not.\n\nI am a real live example of this. For our Delphi projects at work, I\nwant to check it out with LF on my Linux machine (so I can\npatch/diff/merge/grep/edit/etc easily), and CRLF on my Windows machine\n(so that the Delphi IDE doesn't get confused). Other projects I want\nto have pure LF on both Linux and Windows, so setting\ncore.autocrlf=true globally will break things.\n\nEyvind's proposal (or a similar proposal where his new attribute is\njust the crlf attribute) will get me and all my co-workers the\nwonderful correct behaviour *by default*; the current behaviour, or an\nin-repo .gitconfig, will not. The key feature is the new\ncore.eolStyle option, not whether or not we add a new attribute.\n\n> That said, I don't think the extra .gitconfig is even worth it, the same\n> way I do _not_ think Eyvind's extra .gitattributes things are worth it.\n\nDo you even use any CRLF projects? If not, then presumably none of\nthe options will seem worth it. :)\n\nBut the current behaviour really doesn't work for people who need CRLF\nconversion, and an in-repo .gitconfig file won't help them.\ncore.eolStyle + a change to crlf attribute semantics will.\n\nHave fun,\n\nAvery\n"},{"id":"141167","messageId":"alpine.LFD.2.00.1005071303040.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"g2s32541b131005071258s92e058bakc8f3a4df1e1dc634@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T20:06:14Z","receivedAt":"2010-05-07T20:06:14Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Avery Pennarun wrote:\n> \n> No! The whole point is that each user *does* still want to be able to\n> decide how to convert the files tagged by the crlf gitattribute (or a\n> new attribute, I don't care).\n\nAvery, you really don't _get_ it, do you?\n\nIf you want to set how the autocrlf conversion would be done, JUST DO IT. \nThe .gitconfig file would be overridden by your personal settings.\n\nSo what you'd have is\n\n .gitconfig: core.autocrlf=true\t# to enable .gitattributes\n\nbut then any .git/config setting (to \"input\", say) would still override \nthat repository setting.\n\nEnd result: exactly what you're talking about. With _simpler_ syntax than \nthe one Eyvind had.\n\nNow, the thing is, we can go for even simpler syntax still, by just making \nthat \".gitconfig: core.autocrlf=true\" entirely unnecessary. \n\n\t\tLinus\n"},{"id":"141166","messageId":"t2g32541b131005071306v580560c4gb524e9456604298d@mail.gmail.com","threadId":"23705","inReplyTo":"20100507194140.GC7963@pvv.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T20:06:45Z","receivedAt":"2010-05-07T20:06:45Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 3:41 PM, Finn Arne Gangstad wrote:\n> Maybe it is sufficient to add a new value to \"crlf\" that means:\n>\n> - If the file is autodetected as text:\n>  - Convert to LF only on commit, and\n>  - Convert to your preferred EOL style on checkout.\n>\n> I don't think autocrlf is a good place to specify preferred EOL\n> style, it is too dangerous to set autocrlf to true by default, but it should\n> not be dangerous to say that your preferred EOL style is CRLF.\n\nAssuming it's updated to reuse the existing crlf attribute instead of\nadding a new one, that seems to be exactly what this patch series is\nabout. \"Your preferred EOL style\" is the newly introduced\ncore.eolStyle config option. So... good idea :)\n\nHave fun,\n\nAvery\n"},{"id":"141169","messageId":"3FDD45D5-102F-4D78-B459-630C0791BE9B@gmail.com","threadId":"23705","inReplyTo":"7v4oijhdsi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-07T20:11:46Z","receivedAt":"2010-05-07T20:11:46Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 7. mai 2010, at 18.33, Junio C Hamano wrote:\n\n> Eyvind Bernhardsen writes:\n> \n>> - An attribute called \"auto-eol\" is set in the repository to turn on\n>> normalization of line endings. Since attributes are content, the\n>> setting is copied when the repository is cloned and can be changed in\n>> an existing repository (with a few caveats). Setting this attribute\n>> is equivalent to setting \"core.autocrlf\" to \"input\" or \"true\".\n> \n> In what way is this attribute different from existing \"crlf\" attribute?\n\nAvery and Linus have covered this quite well, but I think I can use \"crlf\" instead of inventing a new attribute. New patch series to come.\n\n> It feels as if this series is fixing shortcomings of the combination of\n> core.autocrlf configuration and crlf attribute while trying very hard to\n> keep their shortcomings when the user doesn't say so. What is the\n> downside of making the existing \"core.autocrlf\" + \"crlf\" combination do\n> what your patch wanted to do without retaining this \"keep the existing\n> shortcomings for backward compatibility\"?\n\nI think keeping the existing shortcomings is partly necessary because I don't want to break any existing repositories by changing the meaning of \"core.autocrlf=input\" and \"core.autocrlf=true\".\n\nI also like \"core.eolStyle\" because I want a config setting that explicitly says \"crlf\" or \"lf\" rather than forcing the user to remember what \"true\" and \"input\" mean. The new series will keep core.eolStyle.\n\nI would like to have a boolean \"core.autocrlf\" that uses \"core.eolStyle\" instead of implying anything about line endings in the working directory, but I'm not sure if that is possible without breaking anybody's setup.\n\n>> 1. Setting core.autocrlf in your global or system configuration is a\n>> pain\n> \n> This is a wrong thing to do to begin with, and not worth discussing. You\n> know and your readers know that line ending convention in the repository\n> data (i.e. blobs) is under project control while line ending convention in\n> the working tree is end user preference.\n\nI think it's worth mentioning because git doesn't currently enforce line ending normalization on a per-project basis, which is what I'm trying to rectify. Also, the default setting in msysgit is \"core.autocrlf=true\", but I guess you disagree with that default :)\n\n>> 2. Setting core.autocrlf in an individual repository would be okay\n>> except that naive users will do it after they have already cloned:\n>> unless core.autocrlf is set globally, the clone will have the wrong line\n>> endings, and the user needs to know how to refresh it manually (rm -rf *\n>> && git checkout -f).\n> \n> This may be a worthy goal. But if a \"auto-eol\" attribute \"fixes\" this,\n> perhaps \"crlf\" attribute can be taught to fix it the same way, no?\n\nYes. And it shall!\n-- \nEyvind\n"},{"id":"141171","messageId":"alpine.LFD.2.00.1005071306190.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071303040.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T20:17:12Z","receivedAt":"2010-05-07T20:17:12Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Linus Torvalds wrote:\n> \n> Now, the thing is, we can go for even simpler syntax still, by just making \n> that \".gitconfig: core.autocrlf=true\" entirely unnecessary. \n\nExact semantics I'd suggest for 'core.autocrlf':\n\n Setting\t\tpath in .gitattributes\tpath _not_ in .gitattributes\n =======\t\t======================\t===========================\n - not set at all\tattribute value\t\tno crlf\n - \"off\"/\"false\"\tno crlf\t\t\tno crlf\n - \"on\"\t\t\tattribute value\t\tautocrlf\t\n - \"input\"\t\tattribute \"input\"\tautocrlf \"input\"\n\nWhich is different from what we do now for the \"not set at all\" case, \nin that it still takes the .gitattributes value for those cases if a path \nmatches.\n\nWe could add a few core.autocrlf entries, like \"force\" (to force output to \nbe CRLF even on a platform where it isn't the default).\n\n\t\t\tLinus\n"},{"id":"141178","messageId":"alpine.LFD.2.00.1005071626040.14468@xanadu.home","threadId":"23705","inReplyTo":"m2g32541b131005071236u962d2c73n85d25093d1e048bb@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-05-07T20:29:18Z","receivedAt":"2010-05-07T20:29:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 7 May 2010, Avery Pennarun wrote:\n\n> On Fri, May 7, 2010 at 3:31 PM, Nicolas Pitre wrote:\n> > On Fri, 7 May 2010, Linus Torvalds wrote:\n> >> Btw, another option might be to start searching \".gitconfig\", but only\n> >> allow a certain \"safe subset\" of config options in that. Things that can\n> >> really be about the project itself, and not per-user or per-repository.\n> >>\n> >> And parse it before ~/.gitconfig and .git/config, so that people can\n> >> always override it.\n> >>\n> >> I dunno. Looking at the config options, there really aren't a lot of them\n> >> that make sense on a project scale. There's a few, though. Things like\n> >>\n> >>       core.autocrlf\n> >>       i18n.commitEnconfig\n> >>\n> >> and possibly others..\n> >\n> > Given that only a subset of gitconfig could make sense to have\n> > distributed, I think the file should be named .gitparams to make the\n> > distinction clear.\n> \n> Since the options it *does* have are exactly the same as .git/config,\n> however, naming it .gitconfig makes sense.\n\nWell, I disagree.\n\n> I'd say just print a\n> warning when reading options that are going to be ignored for security\n> reasons (or because they're not known at all, or whatever).\n\nOr just make it .gitparams (or anything you wish) which is not the same \nas gitconfig. This way it is less likely to get bogus bug reports for \noptions that aren't supported.\n\n\nNicolas\n"},{"id":"141179","messageId":"alpine.LFD.2.00.1005071630170.14468@xanadu.home","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071235070.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-05-07T20:32:35Z","receivedAt":"2010-05-07T20:32:35Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 7 May 2010, Linus Torvalds wrote:\n\n> On Fri, 7 May 2010, Nicolas Pitre wrote:\n> > \n> > Given that only a subset of gitconfig could make sense to have \n> > distributed, I think the file should be named .gitparams to make the \n> > distinction clear.\n> \n> I went through the options listed in \"man gitconfig\", and quite frankly, I \n> didn't find any new ones. I didn't grep the source, and I'm sure they're \n> not all documented, but if it really is just two options, I doubt it's \n> worth it at all.\n\nI don't dispute that.\n\nI was merely pointing out that naming such a file .gitconfig is a bad \nidea if it doesn't duplicate the entire .git/config functionality.\n\n\nNicolas\n"},{"id":"141180","messageId":"576B55DC-C92D-4FEB-B4E8-4A042D6F024B@gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071306190.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-07T20:42:07Z","receivedAt":"2010-05-07T20:42:07Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 7. mai 2010, at 22.17, Linus Torvalds wrote:\n\n> \n> \n> On Fri, 7 May 2010, Linus Torvalds wrote:\n>> \n>> Now, the thing is, we can go for even simpler syntax still, by just making \n>> that \".gitconfig: core.autocrlf=true\" entirely unnecessary. \n> \n> Exact semantics I'd suggest for 'core.autocrlf':\n> \n> Setting\t\tpath in .gitattributes\tpath _not_ in .gitattributes\n> =======\t\t======================\t===========================\n> - not set at all\tattribute value\t\tno crlf\n> - \"off\"/\"false\"\tno crlf\t\t\tno crlf\n> - \"on\"\t\t\tattribute value\t\tautocrlf\t\n> - \"input\"\t\tattribute \"input\"\tautocrlf \"input\"\n> \n> Which is different from what we do now for the \"not set at all\" case, \n> in that it still takes the .gitattributes value for those cases if a path \n> matches.\n> \n> We could add a few core.autocrlf entries, like \"force\" (to force output to \n> be CRLF even on a platform where it isn't the default).\n\nHow can you say that this is simpler than my syntax? I have an attribute that means \"line endings should be normalised\" and a configuration variable that decides what line endings should be used in the working directory for normalised files. If you like CRLFs you set it to \"crlf\", if you like LFs you set it to \"lf\".\n\nI'll replace \"auto-eol\" with something like \"crlf=auto\" because I actually think that's pretty neat, but I won't pretend that \"true\" and \"input\" are sane ways to indicate if you prefer CRLF or LF line endings in your working directory.\n-- \nEyvind\n"},{"id":"141185","messageId":"alpine.LFD.2.00.1005071355380.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"576B55DC-C92D-4FEB-B4E8-4A042D6F024B@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T20:57:39Z","receivedAt":"2010-05-07T20:57:39Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n> \n> How can you say that this is simpler than my syntax?\n\nBecause your syntax adds totally new attributes, so now you can't even \ntake an existing .gitattributes and make it do something sane - instead \nyou have to write totally new rules.\n\nMy suggestion just makes any existing usage do the \"what you'd expect\".\n\nTHAT is simpler.\n\n\t\tLinus\n"},{"id":"141183","messageId":"q2t32541b131005071358p2abd2fc2la2f128e8ab721882@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071303040.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T20:58:01Z","receivedAt":"2010-05-07T20:58:01Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 4:06 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> No!  The whole point is that each user *does* still want to be able to\n>> decide how to convert the files tagged by the crlf gitattribute (or a\n>> new attribute, I don't care).\n>\n> Avery, you really don't _get_ it, do you?\n\nI was going to say that I do get it, but I guess I didn't. You're\nright, your proposal is functionally equivalent. Feel free to stop\nreading the rest of this post :)\n\nFor the benefit of those who might have misunderstood as I did, the\nreason they're equivalent is that \"core.eolStyle = LF\" is the same as\nsaying \"never do EOL conversion\" since an unconverted file is\nimplicitly LF. And there is already a way to say \"never do EOL\nconversion,\" which is to set core.autocrlf=False.\n\nBy adding core.autocrlf=True to an in-project .gitconfig file, we can\nfix a mistake in the original definition of the crlf attribute, ie.,\nit should be able to force CRLF conversion even when a user hasn't set\ncore.autocrlf explicitly. But that new ability doesn't take away a\nperson's ability to override it globally because .git/config and\n~/.gitconfig take precedence. Notably, this solution doesn't break\nany backward compatibility.\n\nLinus's second proposed option would be to slightly change the way the\ncrlf attribute works, by making core.autocrlf a tri-state variable\ninstead of just true/false. \"Undefined\" would mean \"use the crlf\nattribute\" where currently it means (rather unhelpfully) \"always use\nLF even if .gitattributes says otherwise.\" However, this would be a\nbackward-incompatible change. Arguably, not one that anyone would\ncare about. (For the record, none of my co-workers would care. The\ncurrent behaviour is sufficiently unhelpful that we have to use\ncore.autocrlf=True anyway, so .gitattributes crlf hasn't been useful.)\n\nNow, arguably, the current semantics, and even Linus's proposed\nimproved semantics, are still pretty hard to explain. \"This file\nshould always be unchanged\" and \"this file should always use native\nline endings\" and \"this is my native line ending style\" is very simple\nand straightforward. But I'm sure others would argue the opposite,\nand it's just a matter of preference.\n\nHave fun,\n\nAvery\n"},{"id":"141186","messageId":"n2l32541b131005071400uf90ab0e8se882fce6b3abf522@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071626040.14468@xanadu.home","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T21:00:39Z","receivedAt":"2010-05-07T21:00:39Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 4:29 PM, Nicolas Pitre wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> Since the options it *does* have are exactly the same as .git/config,\n>> however, naming it .gitconfig makes sense.\n>\n> Well, I disagree.\n>\n>> I'd say just print a\n>> warning when reading options that are going to be ignored for security\n>> reasons (or because they're not known at all, or whatever).\n>\n> Or just make it .gitparams (or anything you wish) which is not the same\n> as gitconfig. This way it is less likely to get bogus bug reports for\n> options that aren't supported.\n\nIt has exactly the same syntax as ~/.gitconfig, and the options it\ndoes support can all be carried over literally to ~/.gitconfig.\nCalling it something else would imply that it deserves its own man\npage, which would need to repeat all the options that are already\ndocumented for ~/.gitconfig.\n\nI'd say something that's syntactically identical, and in some cases\nactually interchangeable, should have the same name. Using a\ndifferent name could actually be *misleading*.\n\nHave fun,\n\nAvery\n"},{"id":"141188","messageId":"alpine.LFD.2.00.1005071708090.14468@xanadu.home","threadId":"23705","inReplyTo":"n2l32541b131005071400uf90ab0e8se882fce6b3abf522@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-05-07T21:12:24Z","receivedAt":"2010-05-07T21:12:24Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 7 May 2010, Avery Pennarun wrote:\n\n> On Fri, May 7, 2010 at 4:29 PM, Nicolas Pitre wrote:\n> > On Fri, 7 May 2010, Avery Pennarun wrote:\n> >> Since the options it *does* have are exactly the same as .git/config,\n> >> however, naming it .gitconfig makes sense.\n> >\n> > Well, I disagree.\n> >\n> >> I'd say just print a\n> >> warning when reading options that are going to be ignored for security\n> >> reasons (or because they're not known at all, or whatever).\n> >\n> > Or just make it .gitparams (or anything you wish) which is not the same\n> > as gitconfig. This way it is less likely to get bogus bug reports for\n> > options that aren't supported.\n> \n> It has exactly the same syntax as ~/.gitconfig, and the options it\n> does support can all be carried over literally to ~/.gitconfig.\n\nAbsolutely not.\n\nMost options for ~/.gitconfig simply make no sense in a distributed \n.gitconfig file.\n\n> Calling it something else would imply that it deserves its own man\n> page, which would need to repeat all the options that are already\n> documented for ~/.gitconfig.\n\nNo because most of those options don't and can't apply to a distributed \noption file.\n\n> I'd say something that's syntactically identical, and in some cases\n> actually interchangeable, should have the same name.\n\nIndeed. But this is not the case here.\n\n\nNicolas\n"},{"id":"141189","messageId":"384AA932-227B-43B0-9D38-560A3567918A@gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071355380.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-07T21:17:02Z","receivedAt":"2010-05-07T21:17:02Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 7. mai 2010, at 22.57, Linus Torvalds wrote:\n\n> On Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n>> \n>> How can you say that this is simpler than my syntax?\n> \n> Because your syntax adds totally new attributes, so now you can't even \n> take an existing .gitattributes and make it do something sane - instead \n> you have to write totally new rules.\n\nI don't understand. All you have to do is add \"* auto-eol=true\" to your .gitattributes, and line endings will be normalized exactly as if you'd set \"core.autocrlf\". Why would you have to write totally new rules? Which rules?\n\n> My suggestion just makes any existing usage do the \"what you'd expect\".\n> \n> THAT is simpler.\n\nWell, sort of, but \"simple for someone who already knows how core.autocrlf works\" isn't what I'm aiming for :)\n-- \nEyvind\n"},{"id":"141190","messageId":"alpine.LFD.2.00.1005071421340.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"384AA932-227B-43B0-9D38-560A3567918A@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T21:23:45Z","receivedAt":"2010-05-07T21:23:45Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n> \n> I don't understand. All you have to do is add \"* auto-eol=true\" to your \n> .gitattributes, and line endings will be normalized exactly as if you'd \n> set \"core.autocrlf\". Why would you have to write totally new rules? \n> Which rules?\n\nI think \"* auto-eol=true\" is just crazy. We would _never_ want to do that. \nAny project that does that should be shot in the head.\n\nSo encouraging that as a format is just silly and stupid.\n\nIn contrast, the slight change in semantics (with no new config options \n_or_ attributes) that I suggest should just make everybody happy - because \nit takes care of the real life situation that people are in.\n\n\t\tLinus\n"},{"id":"141191","messageId":"x2j32541b131005071426tb875cc1dtcc26e86d868d2e8b@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071708090.14468@xanadu.home","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T21:26:25Z","receivedAt":"2010-05-07T21:26:25Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 5:12 PM, Nicolas Pitre wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> It has exactly the same syntax as ~/.gitconfig, and the options it\n>> does support can all be carried over literally to ~/.gitconfig.\n>\n> Absolutely not.\n>\n> Most options for ~/.gitconfig simply make no sense in a distributed\n> .gitconfig file.\n\nNo, that's the converse of what I said.\n\nTry this in your head:\n\n cp .gitconfig .git/config\n\nPerfectly valid. Copying the other way might (or might not) result in\ninvalid options in .gitconfig, which probably ought to be warned\nabout. But the syntax is obviously identical.\n\n>> Calling it something else would imply that it deserves its own man\n>> page, which would need to repeat all the options that are already\n>> documented for ~/.gitconfig.\n>\n> No because most of those options don't and can't apply to a distributed\n> option file.\n\nBut the ones that *do* apply all have the same meanings.\n\n>> I'd say something that's syntactically identical, and in some cases\n>> actually interchangeable, should have the same name.\n>\n> Indeed.  But this is not the case here.\n\nHmm, how to name the file is most a matter of opinion, but this last\nbit is just factual ;) They're syntactically identical. And in some\ncases, they're interchangeable. I don't see how one could argue\notherwise.\n\nHave fun,\n\nAvery\n"},{"id":"141192","messageId":"m2z32541b131005071430vcd851ac8yd3c783429a84f875@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071421340.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T21:30:20Z","receivedAt":"2010-05-07T21:30:20Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 5:23 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n>> I don't understand.  All you have to do is add \"* auto-eol=true\" to your\n>> .gitattributes, and line endings will be normalized exactly as if you'd\n>> set \"core.autocrlf\".  Why would you have to write totally new rules?\n>> Which rules?\n>\n> I think \"* auto-eol=true\" is just crazy. We would _never_ want to do that.\n> Any project that does that should be shot in the head.\n\nIn the interests of further making myself look like an idiot:\n\nJust to clarify, is it crazy because that line would convert all\nfiles, even binary ones, where core.autocrlf auto-detects whether\nfiles are binary or text?\n\nAvery\n"},{"id":"141194","messageId":"FA7479D2-1859-4F8B-AC94-013BD6A4F608@bernhardsen.org","threadId":"23705","inReplyTo":"m2z32541b131005071430vcd851ac8yd3c783429a84f875@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind@bernhardsen.org","sentAt":"2010-05-07T21:37:20Z","receivedAt":"2010-05-07T21:37:20Z","isPatch":true,"sender":{"key":"eyvind@bernhardsen.org","avatar":null},"body":"On 7. mai 2010, at 23.30, Avery Pennarun wrote:\n\n> On Fri, May 7, 2010 at 5:23 PM, Linus Torvalds\n> wrote:\n>> On Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n>>> I don't understand. All you have to do is add \"* auto-eol=true\" \n>>> to your\n>>> .gitattributes, and line endings will be normalized exactly as if \n>>> you'd\n>>> set \"core.autocrlf\". Why would you have to write totally new rules?\n>>> Which rules?\n>>\n>> I think \"* auto-eol=true\" is just crazy. We would _never_ want to \n>> do that.\n>> Any project that does that should be shot in the head.\n>\n> In the interests of further making myself look like an idiot:\n>\n> Just to clarify, is it crazy because that line would convert all\n> files, even binary ones, where core.autocrlf auto-detects whether\n> files are binary or text?\n\nJust to clarify a bit more, that is _not_ what it would do. The \n\"crlf\" attribute is still respected, of course.\n\nAlso, I meant to write \"* crlf=auto\", not \"* auto-eol=true\", if that \nmakes it any less crazy.\n-- \nEyvind\n"},{"id":"141193","messageId":"alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"m2z32541b131005071430vcd851ac8yd3c783429a84f875@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T21:54:40Z","receivedAt":"2010-05-07T21:54:40Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Avery Pennarun wrote:\n>\n> > I think \"* auto-eol=true\" is just crazy. We would _never_ want to do that.\n> > Any project that does that should be shot in the head.\n>\n> Just to clarify, is it crazy because that line would convert all\n> files, even binary ones, where core.autocrlf auto-detects whether\n> files are binary or text?\n\nNo, presumably 'auto-eol' does the same auto-detection. Otherwise the name \nwouldn't make sense.\n\nI just think that it's crazy because\n\n (a) you should try to avoid do things like that in the first place. For \n something like an attribute file, you should just list the files you \n want to convert. That's the _point_ of an attribute. So it's much \n nicer if you instead actually are explicit about it, ie\n\n\t*.[ch] crlf\n\t*.txt crlf\n\t*.jpg -crlf\n\n should be the _primary_ way you do it, since the autocrlf thing is a \n bit dangerous in theory.\n\n (b) But let's say that you want to do it anyway (because you're lazy \n and because autocrlf works pretty damn well in practice), isn't that \n a really ugly and crazy thing to add _another_ attribute name for \n that?\n\n IOW, if you really want to say \"do automatic crlf for this set of \n paths\", the natural syntax for that would be\n\n\t* crlf=auto\n\n No? Not some totally new attribute name.\n\nAnd in the end, you always do want to have a config variable for the \nactual type of conversion. And like it or not, we already do end up having \nthis mix-up between .gitattributes and git \"core.autocrlf\" config entry, \nso my suggested rule was kind of a \"minimally invasive\" suggestion to just \nturn that mixing of attributes and config entries into something more \npractically useful.\n\n\t\tLinus\n"},{"id":"141195","messageId":"alpine.LFD.2.00.1005071455180.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"FA7479D2-1859-4F8B-AC94-013BD6A4F608@bernhardsen.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T21:58:09Z","receivedAt":"2010-05-07T21:58:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Eyvind Bernhardsen wrote:\n> \n> Also, I meant to write \"* crlf=auto\", not \"* auto-eol=true\", if that makes it\n> any less crazy.\n\nOh, yes. See my other email. \"* crlf=auto\" is at least sensible, although \nsomewhat scary. At least with core.autocrlf=true, the user has to had \nconsciously set it. It was the \"whole new attribute name\" that I thought \npushed it from \"slightly scary\" to \"crazy\".\n\n\t\tLinus\n"},{"id":"141196","messageId":"4BE48F84.3050200@gmail.com","threadId":"23705","inReplyTo":"x2j32541b131005071426tb875cc1dtcc26e86d868d2e8b@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-05-07T22:09:08Z","receivedAt":"2010-05-07T22:09:08Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Avery Pennarun wrote:\n[...]\n> cp .gitconfig .git/config\n> \n> Perfectly valid. Copying the other way might (or might not) result in\n> invalid options in .gitconfig, which probably ought to be warned\n> about. But the syntax is obviously identical.\n[...]\n\nWhich one takes precedence? I *MUST* be able to override a distributed \n.gitconfig/.gitparams/.gitparameters file.\n"},{"id":"141197","messageId":"o2l32541b131005071510x492269dz84e9cc35bfa04942@mail.gmail.com","threadId":"23705","inReplyTo":"4BE48F84.3050200@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T22:10:21Z","receivedAt":"2010-05-07T22:10:21Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 6:09 PM, A Large Angry SCM wrote:\n> Avery Pennarun wrote:\n>>    cp .gitconfig .git/config\n>>\n>> Perfectly valid.  Copying the other way might (or might not) result in\n>> invalid options in .gitconfig, which probably ought to be warned\n>> about.  But the syntax is obviously identical.\n>\n> Which one takes precedence? I *MUST* be able to override a distributed\n> .gitconfig/.gitparams/.gitparameters file.\n\nYes, absolutely. As Linus said, the in-project file is lower priority\nthan your .git/config and ~/.gitconfig files.\n\nAvery\n"},{"id":"141199","messageId":"alpine.LFD.2.00.1005071504280.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T22:14:24Z","receivedAt":"2010-05-07T22:14:24Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Linus Torvalds wrote:\n> \n> IOW, if you really want to say \"do automatic crlf for this set of \n> paths\", the natural syntax for that would be\n> \n> \t* crlf=auto\n\nBtw, since we're discussing this, I do think that our current \"crlf=input\" \nsyntax for .gitattributes is pretty dubious. \n\nI don't really see why it should be a path-dependent thing on whether you \ndo crlf conversion on just input or on checkout too. It smells odd. It \nmakes more sense to me to have a global policy for what the output/input \nconversion should be, and then the path rules are just about whether that \nconversion gets done or not.\n\nAnd like it or not, we called that global rule \"autocrlf\", and then mixed \nit up with the decision on whether we should do conversion at all. I do \nthink that that was a mistake too, and that we could try to fix it, but I \nalso think that's a fairly independent issue.\n\nSo we _could_ introduce a new \"core.crlf\" config option that talks purely \nabout what kind of conversion gets done - not about _whether_ it gets \ndone. So you could do\n\n\t[core]\n\t\tcrlf=input\n\nand it would imply that crlf conversion is only done on input, but it \nwould differ from \"autocrlf=input\" in that it would _not_ imply that any \npaths not matched by gitattributes crlf rules would be automatically \nconverted.\n\n[ And in the above model, \"core.autocrlf = input\" would just be a \n shorthand for saying \"core.autocrlf=true\" + \"core.crlf=input\")\n\nSo I think we could improve the config file syntax a bit.\n\nBut I think that's really a separate issue from the .gitattributes file, \nand whether the \"crlf\" attribute means anythin in the _absense_ of any \nconfig file rules about crlf.\n\n\t\t\tLinus\n"},{"id":"141200","messageId":"i2l32541b131005071519nf49f8703s76f42f4fe9939b6f@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T22:19:52Z","receivedAt":"2010-05-07T22:19:52Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 5:54 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> > I think \"* auto-eol=true\" is just crazy. We would _never_ want to do that.\n>> > Any project that does that should be shot in the head.\n>>\n>> Just to clarify, is it crazy because that line would convert all\n>> files, even binary ones, where core.autocrlf auto-detects whether\n>> files are binary or text?\n>\n> No, presumably 'auto-eol' does the same auto-detection. Otherwise the name\n> wouldn't make sense.\n> [...]\n> Eyvind Bernhardsen wrote:\n>> Also, I meant to write \"* crlf=auto\", not \"* auto-eol=true\", if that makes it\n>> any less crazy.\n>\n> Oh, yes. See my other email. \"* crlf=auto\" is at least sensible, although\n> somewhat scary. At least with core.autocrlf=true, the user has to had\n> [...]\n>  (b) But let's say that you want to do it anyway (because you're lazy\n>     and because autocrlf works pretty damn well in practice), isn't that\n>     a really ugly and crazy thing to add _another_ attribute name for\n>     that?\n>\n>     IOW, if you really want to say \"do automatic crlf for this set of\n>     paths\", the natural syntax for that would be\n>\n>        * crlf=auto\n\nOh, good grief, I'm just getting more and more confused.\n\nSo just to keep all of this straight, I think there are still two\nproposals under consideration here:\n\na) add an in-project .gitconfig, in which case the above crlf=auto is\nexactly equivalent to \"crlf attribute missing\" (which is different\nfrom \"crlf unset\", hee hee, are we having fun yet?) since the crlf\nattribute is ignored unless core.autocrlf=true, and missing means to\nuse the core.autocrlf setting;\n\nOR\n\nb) change the semantics of the crlf attribute, in which case crlf=auto\nis a new mode that means \"use autocrlf on this file even if\ncore.autocrlf is unset or unspecified\".\n\nRight? So in case (a), the new crlf=auto option is unneeded. Though\nit does seem as if we're trending toward case (b).\n\nThanks,\n\nAvery\n"},{"id":"141201","messageId":"h2q32541b131005071534r22cc2092t2a21bfad6d4bfd81@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071504280.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-07T22:34:55Z","receivedAt":"2010-05-07T22:34:55Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 6:14 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Linus Torvalds wrote:\n>>      IOW, if you really want to say \"do automatic crlf for this set of\n>>      paths\", the natural syntax for that would be\n>>\n>>       * crlf=auto\n>\n> Btw, since we're discussing this, I do think that our current \"crlf=input\"\n> syntax for .gitattributes is pretty dubious.\n>\n> I don't really see why it should be a path-dependent thing on whether you\n> do crlf conversion on just input or on checkout too.\n\nMe neither. However, in the name of sanity, it sure would be great to\nhave the global configuration options exactly parallel the per-project\nand per-file configuration options. From that point of view, 'input'\nexists just to keep things nice and symmetrical. And considering how\ncomplicated this discussion already is (compared to what a simple\nconcept CRLF conversion is), that's probably worth something in\nitself.\n\nPart of the confusion comes from the way the options are currently\ndeclared. set vs. unset vs. unspecified vs. \"input\" vs. \"auto\" for an\noption named \"crlf\" is just very, very, unfriendly. None of the words\n*mean* anything.\n\nMaybe we should rethink this from the top. Imagine that we currently\nhave no crlf options whatsoever. What *should* it look like? I\nsuggest the following:\n\nConfig:\n core.eolOverride = lf / crlf / auto / binary / input\n core.eolDefault = lf / crlf / auto / binary / input\n\nAttribute:\n eol = lf / crlf / auto / binary / input\n\nIf eolOverride is not \"auto\" or unspecified, we ignore eolDefault or\nany attributes.\n\nIf the attribute is not \"auto\" or unspecified, we ignore eolDefault.\n\nFor all entries, unspecified is equivalent to \"auto\".\n\nOf course the eol attribute could be named \"crlf\", but that might not\nincrease the sanity as much as we would like.\n\nAnd \"input\" means \"auto, but strip CR when committing.\" Or maybe the\nproblem is that it doesn't belong here at all: maybe it should be an\nentirely separate attribute that takes effect whenever the eol\nattribute/config resolves to \"auto.\"\n\nOr maybe I'm just not thinking about it the right way?\n\nAvery\n"},{"id":"141202","messageId":"x2i600158c31005071554pdc399a46s1f97b1ddcd258d3e@mail.gmail.com","threadId":"23705","inReplyTo":"h2q32541b131005071534r22cc2092t2a21bfad6d4bfd81@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-07T22:54:55Z","receivedAt":"2010-05-07T22:54:55Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"> Part of the confusion comes from the way the options are currently\n> declared.  set vs. unset vs. unspecified vs. \"input\" vs. \"auto\" for an\n> option named \"crlf\" is just very, very, unfriendly.  None of the words\n> *mean* anything.\n>\n> Maybe we should rethink this from the top.  Imagine that we currently\n> have no crlf options whatsoever.  What *should* it look like?  I\n> suggest the following:\n>\n> Config:\n>   core.eolOverride = lf / crlf / auto / binary / input\n>   core.eolDefault = lf / crlf / auto / binary / input\n>\n> Attribute:\n>   eol = lf / crlf / auto / binary / input\n>\n> If eolOverride is not \"auto\" or unspecified, we ignore eolDefault or\n> any attributes.\n>\n> If the attribute is not \"auto\" or unspecified, we ignore eolDefault.\n>\n> For all entries, unspecified is equivalent to \"auto\".\n>\n> Of course the eol attribute could be named \"crlf\", but that might not\n> increase the sanity as much as we would like.\n>\n> And \"input\" means \"auto, but strip CR when committing.\"  Or maybe the\n> problem is that it doesn't belong here at all: maybe it should be an\n> entirely separate attribute that takes effect whenever the eol\n> attribute/config resolves to \"auto.\"\n>\n> Or maybe I'm just not thinking about it the right way?\n>\n> Avery\n>\n\nIf we forget everything git has now, I would suggest the following:\n\n- eol-normalization is per repository, per filetype (fnmatch filter)\n- in a file separate from .git/config, such as .git/eol\n- when you clone, you get this file\n\nYou specifies the 'standard' eol type for each file type in this project:\n\n *.c lf\n *.python lf\n *.vb crlf\n *.sln crlf\n etc (something like that)\n\ncommitting and checking-out always normalize line endings; *always*\n\nadd (and commit) can take an option to keep eol as-is (i.e.\n--no-eol-normalization or --keep-eol or --raw-eol)\n\nIn this model:\n\n1- Anyone who clones gets the repository eol settings\n2- No one can possibly commit in a different eol style unless he\nexplicitly says he wants to.\n3- Naturally, eol-normalization doesn't apply to binary files\n\n#2 is important, it's needed so you won't have someone making bad\ncommits because he has a settings some where in his global config to\nalways ignore eol normalization.\non the other hand, one can alias 'add --raw-eol' to something like\n'eviladd', so he can do 'git eviladd file.c', which is fine because\nit's explicit.\n\nThis would get rid of issues where an editor (such as VS) saves a file\nwith mixed line endings: we don't care because we normalize them.\n\nThis would also make it more transparent to windows users: they don't\neven have to think about eol issues; they can't make bad commits\n\"by-accident\". (provided the repo maintainer has set the eol filters\nproperly).\n\nI have no idea what happens (or should happen) if the origin repo\nmaintainer updates the .git/eol file. Maybe it should be .giteol\ninstead of .git/eol\n"},{"id":"141206","messageId":"alpine.LFD.2.00.1005071601470.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"h2q32541b131005071534r22cc2092t2a21bfad6d4bfd81@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T23:18:28Z","receivedAt":"2010-05-07T23:18:28Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, Avery Pennarun wrote:\n> \n> Maybe we should rethink this from the top. Imagine that we currently\n> have no crlf options whatsoever. What *should* it look like? I\n> suggest the following:\n> \n> Config:\n> core.eolOverride = lf / crlf / auto / binary / input\n> core.eolDefault = lf / crlf / auto / binary / input\n\nUgh. Hell no. What an ugly format. What does that crazy \"override vs \ndefault\" even _mean_?\n\nSo no.\n\nPlus the above is confused anyway. The only reason to ever support 'lf' is \nif you're a total moron of a SCM, and you save files you know are text in \nCRLF format internally. That's just f*cking stupid.\n\nSo the above is just crazy talk.\n\nThe options that make sense is:\n\n - disabling all \"text\" issues, and considering everything to be pure \n binary. This is the \"I know I'm sane and unix\" option, or the \"doing \n any conversion is always wrong\" option.\n\n We'd call this \"binary\" or \"off\" or \"false\".\n\n - if you recognize a text-file, and consider it text and different from \n binary, at a _minimum_ it needs what we call \"input\". Anything else is \n crazy-talk. We don't save the same text-file in different formats, and \n we know that CRLF (or CR) is just a stupid format for text.\n\n So there are zero options for the input side. If we don't do CRLF -> LF \n conversion on input, it's worthless even _talking_ about text vs binary.\n\n - For output, there are exactly three choices: \"do nothing\" (aka just \n \"input\", aka \"LF\"), output in native format (CRLF on Windows, LF on \n UNIX), or \"force CRLF\" regardless of any defaults (and the last \n probably doesn't make sense in practice, but is good for test-suites, \n so that you can get CRLF output even on sane platforms.\n\nSo I think the _only_ sane choices are basically\n\n\tcore.crlf=[off|input|on|force]\n\nwhere you may obviously have aliases (ie \"off\", \"false\" and \"binary\" could \nall mean the same thing, and you could alias \"input\" to \"lf\" and \"force\" \nto \"crlf\").\n\nAnd the above is basically what we have. Except that for historical \nreasons (ie we didn't even _have_ any attributes) it got mixed it up with \n\"do we want to do this automatically\", so \"autocrlf=on\" actually ends up \nbeing \"yes, do automatic detection\" _and_ what I'd call \"core.crlf=force\" \nabove.\n\n\t\t\tLinus\n"},{"id":"141208","messageId":"q2y600158c31005071647i80871db0z7a55ae77e738d0d4@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071601470.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-07T23:47:13Z","receivedAt":"2010-05-07T23:47:13Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":">\n> The only reason to ever support 'lf' is\n> if you're a total moron of a SCM, and you save files you know are text in\n> CRLF format internally. That's just f*cking stupid.\n>\n\nWhat if:\n\n- The entire history of the file is stored in CRLF\n- It's a windows-only file where the official \"tool\" that reads it\nbarfs on LF line endings.\n- Third party tools also expect (or at least, handle) CRLF line endings.\n\nEven if you end up deciding to store it with LF line endings\ninternally, it should still be *always* checked out with CRLF endings.\n\nAnd no, just because I want certain files to be checked out with CRLF\nendings, doesn't mean that I want all files to be checked out that\nway. This is one of the areas where git's crlf handling is lacking\nright now.\n\nAlso, git-diff should ignore eol differences by default, unless\nexplicitly asked not to (currently it's the other way around).\n"},{"id":"141209","messageId":"alpine.LFD.2.00.1005071648400.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"q2y600158c31005071647i80871db0z7a55ae77e738d0d4@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-07T23:50:04Z","receivedAt":"2010-05-07T23:50:04Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, hasen j wrote:\n\n> >\n> > The only reason to ever support 'lf' is\n> > if you're a total moron of a SCM, and you save files you know are text in\n> > CRLF format internally. That's just f*cking stupid.\n> >\n> \n> What if:\n> \n> - The entire history of the file is stored in CRLF\n> - It's a windows-only file where the official \"tool\" that reads it\n> barfs on LF line endings.\n> - Third party tools also expect (or at least, handle) CRLF line endings.\n\nUmm. Then it's not text, is it? What you are describing is a binary file \nthat happens to look like text with CRLF.\n\nIf it's _text_, then you import it as such, and set crlf=true so that it \ngets checked out with crlf.\n\n\t\tLinus\n"},{"id":"141210","messageId":"i2v600158c31005071719r23db385bpab9a971534b5d7c3@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071648400.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-08T00:19:35Z","receivedAt":"2010-05-08T00:19:35Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 7 May 2010 17:50, Linus Torvalds wrote:\n>\n>\n> On Fri, 7 May 2010, hasen j wrote:\n>\n>> >\n>> > The only reason to ever support 'lf' is\n>> > if you're a total moron of a SCM, and you save files you know are text in\n>> > CRLF format internally. That's just f*cking stupid.\n>> >\n>>\n>> What if:\n>>\n>> - The entire history of the file is stored in CRLF\n>> - It's a windows-only file where the official \"tool\" that reads it\n>> barfs on LF line endings.\n>> - Third party tools also expect (or at least, handle) CRLF line endings.\n>\n> Umm. Then it's not text, is it? What you are describing is a binary file\n> that happens to look like text with CRLF.\n\nThat depends on your definition of text.\n\nStoring it with LF internally is ok, as long as we can have it\n*always* be checked out as crlf.\n\n> If it's _text_, then you import it as such, and set crlf=true so that it\n> gets checked out with crlf.\n\nIt should be the repository maintainer's responsibility to tell git to\nalways checkout that file with crlf.\n\nWhy?\n\nBecause it's part of the project. I never set crlf=true on windows,\nbut if some files just *have* to have crlf, then I wouldn't mind\nhaving them that way.\nThis doesn't mean I should have to pollute all my files with crlf just\nto please visual studio, or whatever tool requires the crlf endings.\n\nOther developers (specially those new to git) shouldn't have to worry\nabout crlf issues: when they clone, git would automatically convert\nsome files to crlf on checkout, regardless of whether or not they set\ncrlf=true.\n\ngit currently has it backward: putting the onus on each individual\ncontributer to set autocrlf=true\n\nThis doesn't make any sense.\n\nIf someone did want everything to be crlf, sure, they can set crlf=true.\n\nBut there's another potential problem: what if some files just *can't*\nhave crlf? Say some build (or whatever) tool barfs on crlf files, and\nthe user sets crlf=true because that's his preferred eol style, but\nthe project has one of those lf-only files? In this case, we'd want\nthat file to be always checked out with LF, even if crlf=true is set.\n"},{"id":"141211","messageId":"i2l32541b131005071731j11085ab4zf325fad96381ce35@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071601470.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-08T00:31:50Z","receivedAt":"2010-05-08T00:31:50Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 7:18 PM, Linus Torvalds\n wrote:\n> On Fri, 7 May 2010, Avery Pennarun wrote:\n>> Maybe we should rethink this from the top.  Imagine that we currently\n>> have no crlf options whatsoever.  What *should* it look like?  I\n>> suggest the following:\n>>\n>> Config:\n>>    core.eolOverride = lf / crlf / auto / binary / input\n>>    core.eolDefault = lf / crlf / auto / binary / input\n>\n> Ugh. Hell no. What an ugly format. What does that crazy \"override vs\n> default\" even _mean_?\n\nThat's easy:\n\n - if \"override\" is set, it overrides any attribute setting.\n - if \"default\" is set, we use it when there's no attribute or override setting.\n\nWe can argue about whether having two config options is strictly\nnecessary from a formal truth table point of view, and you'll probably\nwin the argument because it all makes my head spin. My argument is\nsimpler: if it makes my head spin, it probably makes other people's\nheads spin. The way I described is simple enough for anyone to\nunderstand.\n\n> Plus the above is confused anyway. The only reason to ever support 'lf' is\n> if you're a total moron of a SCM, and you save files you know are text in\n> CRLF format internally. That's just f*cking stupid.\n\nWhat I meant by \"lf\" is just what we currently mean by \"crlf=false\".\nIt's more clear for the average person to say \"eol=lf\" than\n\"crlf=false\", because \"crlf=false\" doesn't say what you *do* want, it\nonly says what you *don't* want.\n\nClearly any repo storing some other weird line ending, then converting\nit to LF, is not what we want here.\n\n>  - disabling all \"text\" issues, and considering everything to be pure\n>   binary. This is the \"I know I'm sane and unix\" option, or the \"doing\n>   any conversion is always wrong\" option.\n>\n>   We'd call this \"binary\" or \"off\" or \"false\".\n\nSure, that's what I called \"binary\" above.\n\n>  - if you recognize a text-file, and consider it text and different from\n>   binary, at a _minimum_ it needs what we call \"input\". Anything else is\n>   crazy-talk. We don't save the same text-file in different formats, and\n>   we know that CRLF (or CR) is just a stupid format for text.\n>\n>   So there are zero options for the input side. If we don't do CRLF -> LF\n>   conversion on input, it's worthless even _talking_ about text vs binary.\n\nThat sounds good to me. So this was a mistake in the original\nimplementation of autocrlf; let's just correct it, and make all text\nmodes do input conversion.\n\nNote that, in prior threads on this topic, there was some objection to\ndoing crlf=anything by default because it wastes CPU in the common\ncase that people are running on Unix and aren't doing screwy things\nwith line endings. Defaulting to crlf=input would require us to waste\nCPU here. Is that ok?\n\n>  - For output, there are exactly three choices: \"do nothing\" (aka just\n>   \"input\", aka \"LF\"), output in native format (CRLF on Windows, LF on\n>   UNIX), or \"force CRLF\" regardless of any defaults (and the last\n>   probably doesn't make sense in practice, but is good for test-suites,\n>   so that you can get CRLF output even on sane platforms.\n>\n> So I think the _only_ sane choices are basically\n>\n>        core.crlf=[off|input|on|force]\n\nOne nice thing about my suggestion is that it completely avoids the\nconcept of a \"native CRLF format.\" Because nowadays, that's just not\nvery useful. On Unix sometimes I need crlf files; on Windows\nsometimes I need lf files. Yes, we can still implement that in terms\nof \"native\" terminology, but it seems to a roundabout way of stating\nwhat I want.\n\n> And the above is basically what we have. Except that for historical\n> reasons (ie we didn't even _have_ any attributes) it got mixed it up with\n> \"do we want to do this automatically\", so \"autocrlf=on\" actually ends up\n> being \"yes, do automatic detection\" _and_ what I'd call \"core.crlf=force\"\n> above.\n\nFunctionally, yes, we have this already. Your new proposal is\nessentially to make crlf=auto (= unspecified) to actually always\ninclude crlf=input behaviour, which sounds good to me, but may be\nbackwards incompatible in some important way. (I wouldn't think\nanybody would want the non-fixing-stuff behaviour. But I wonder what\nit would do to git-svn... maybe it could just check everything in as\nif it were crlf=binary, if it doesn't already.)\n\nMy suggestion doesn't much change this functionality, but attempts to\nstraighten out the terminology so normal humans can understand what\nwill happen. Not sure if that's worth it, given that we'll probably\nhave to support the old attribute names forever anyhow, and adding a\nsecond set of words might confuse normal humans all the more. But I\nwould much rather teach people to use it using my terminology than\ncrlf=true/false/binary terminology. What does \"crlf=binary\" mean?\n\nHave fun,\n\nAvery\n"},{"id":"141212","messageId":"alpine.LFD.2.00.1005071728250.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"i2v600158c31005071719r23db385bpab9a971534b5d7c3@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-08T00:33:01Z","receivedAt":"2010-05-08T00:33:01Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, hasen j wrote:\n\n> On 7 May 2010 17:50, Linus Torvalds wrote:\n> >> What if:\n> >>\n> >> - The entire history of the file is stored in CRLF\n> >> - It's a windows-only file where the official \"tool\" that reads it\n> >> barfs on LF line endings.\n> >> - Third party tools also expect (or at least, handle) CRLF line endings.\n> >\n> > Umm. Then it's not text, is it? What you are describing is a binary file\n> > that happens to look like text with CRLF.\n> \n> That depends on your definition of text.\n\nWell, my definition of text is \"does it make sense to do any end-of-line \nconversions\". That's the only definition that makes sense for an SCM, at \nleast in the current context. If doing conversions on the line endings is \nwrong, then it's not text.\n\nAnd your whole premise was that conversions were always wrong. So the way \nyou put it, that's not a text-file, it's a binary file.\n\n> Storing it with LF internally is ok, as long as we can have it\n> *always* be checked out as crlf.\n\n.. and that's what I suggested \"core.crlf=on\" would mean.\n\nHowever, if you think that it needs to be CRLF on _all_ platforms, even \nplatforms where CRLF is _wrong_ for a text-file, then see above: in that \ncase it's not a text-file at all as far as the SCM is concerned.\n\nIn that case it's just a binary file, and CRLF is _not_ \"end of text \nline\", it's part of the definition of the format for that binary file.\n\n\t\t\tLinus\n"},{"id":"141213","messageId":"i2g600158c31005071839wc5269ffqc88cb26e48c44748@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071728250.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-08T01:39:34Z","receivedAt":"2010-05-08T01:39:34Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 7 May 2010 18:33, Linus Torvalds wrote:\n>\n>\n> On Fri, 7 May 2010, hasen j wrote:\n>\n>> On 7 May 2010 17:50, Linus Torvalds wrote:\n>> >> What if:\n>> >>\n>> >> - The entire history of the file is stored in CRLF\n>> >> - It's a windows-only file where the official \"tool\" that reads it\n>> >> barfs on LF line endings.\n>> >> - Third party tools also expect (or at least, handle) CRLF line endings.\n>> >\n>> > Umm. Then it's not text, is it? What you are describing is a binary file\n>> > that happens to look like text with CRLF.\n>>\n>> That depends on your definition of text.\n>\n> Well, my definition of text is \"does it make sense to do any end-of-line\n> conversions\". That's the only definition that makes sense for an SCM, at\n> least in the current context. If doing conversions on the line endings is\n> wrong, then it's not text.\n>\n> And your whole premise was that conversions were always wrong. So the way\n> you put it, that's not a text-file, it's a binary file.\n>\n>> Storing it with LF internally is ok, as long as we can have it\n>> *always* be checked out as crlf.\n>\n> .. and that's what I suggested \"core.crlf=on\" would mean.\n>\n> However, if you think that it needs to be CRLF on _all_ platforms, even\n> platforms where CRLF is _wrong_ for a text-file, then see above: in that\n> case it's not a text-file at all as far as the SCM is concerned.\n>\n> In that case it's just a binary file, and CRLF is _not_ \"end of text\n> line\", it's part of the definition of the format for that binary file.\n>\n>                        Linus\n>\n\n(sorry about the previous message, forgot to make it reply all)\n\nWhat does the platform care? This doesn't make any sense. Files that\nneed CRLF are not Unix files to begin with (e.g. sln).\n\nMy whole argument is based on a simple premise: LF -> CRLF doesn't\nmake sense because all windows editors can handle LF endings, and\nbecause it just causes a lot of confusion.\n\nUntil Erik brought up the case where a multi-platform project uses\ndifferent build systems on each platform.\n\nI don't know if .sln is one of these formats where the tools will\nvomit if it's not crlf, but let's just assume so.\n\n- *.sln is not a Unix file, so it's perfectly ok (maybe even\ndesirable) to check it out with crlf.\n- it's an exception; git doesn't have to convert _all_ files to crlf;\njust the .sln ones.\n"},{"id":"141214","messageId":"alpine.LFD.2.00.1005071847100.901@i5.linux-foundation.org","threadId":"23705","inReplyTo":"i2g600158c31005071839wc5269ffqc88cb26e48c44748@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-08T01:49:13Z","receivedAt":"2010-05-08T01:49:13Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 7 May 2010, hasen j wrote:\n> > However, if you think that it needs to be CRLF on _all_ platforms, even\n> > platforms where CRLF is _wrong_ for a text-file, then see above: in that\n> > case it's not a text-file at all as far as the SCM is concerned.\n> >\n> > In that case it's just a binary file, and CRLF is _not_ \"end of text\n> > line\", it's part of the definition of the format for that binary file.\n> \n> What does the platform care? This doesn't make any sense. Files that\n> need CRLF are not Unix files to begin with (e.g. sln).\n\nDon't be silly.\n\nThe whole AND ONLY point of CRLF translation is that line-endings are \ndifferent on different platforms.\n\nSo when you say \"What does the platform care?\", that is a totally idiotic \nand utterly stupid thing to ask.\n\nAnd since you ask it, I can only assume that you don't understand anything \nabout the whole CRLF discussion, that you don't care about cross-platform \nrepositories, and that as a result you should NEVER EVER actually use any \nof the git crlf conversion code.\n\nIt's that simple. You seem to totally miss the whole point of the whole \nfeature in the first place.\n\n\t\t\tLinus\n"},{"id":"141216","messageId":"g2h600158c31005071949ve3397f18j3c38017be32dd591@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071847100.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-08T02:49:52Z","receivedAt":"2010-05-08T02:49:52Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":"On 7 May 2010 19:49, Linus Torvalds wrote:\n>\n>\n> On Fri, 7 May 2010, hasen j wrote:\n>> > However, if you think that it needs to be CRLF on _all_ platforms, even\n>> > platforms where CRLF is _wrong_ for a text-file, then see above: in that\n>> > case it's not a text-file at all as far as the SCM is concerned.\n>> >\n>> > In that case it's just a binary file, and CRLF is _not_ \"end of text\n>> > line\", it's part of the definition of the format for that binary file.\n>>\n>> What does the platform care? This doesn't make any sense. Files that\n>> need CRLF are not Unix files to begin with (e.g. sln).\n>\n> Don't be silly.\n>\n> The whole AND ONLY point of CRLF translation is that line-endings are\n> different on different platforms.\n>\n> So when you say \"What does the platform care?\", that is a totally idiotic\n> and utterly stupid thing to ask.\n>\n> And since you ask it, I can only assume that you don't understand anything\n> about the whole CRLF discussion, that you don't care about cross-platform\n> repositories, and that as a result you should NEVER EVER actually use any\n> of the git crlf conversion code.\n>\n> It's that simple. You seem to totally miss the whole point of the whole\n> feature in the first place.\n>\n>                        Linus\n>\n\nI worked on several projects on windows where ALL my files were LF;\nthe platform didn't give a shit and everything worked great.\n\nI don't suppose you use the CRLF feature yourself, not to mention\ndoing any windows development (ever?).\n\nThe way git handles crlf is just confusing; in fact it's so confusing\nthat it's often better to just turn it off. I'm not the only person\nwho thinks that. It's specifically confusing because git thinks \"if\nyou're on windows then ALL your files should be CRLF\", which is\nclearly what you think.\n\nThe platform is not windows, it's the development tools. Most\ndevelopment tools don't actually mind if the line endings are LF only,\nand since CRLF conversions in git cause endless confusion, it's better\nto turn it off most of the time, unless you're dealing with a retarded\ntool that think CRLF is the only line ending and fails to read files\nwith LF endings.\n\nWhen that happens, it's most likely the case that these files are\nplatform-dependent anyway, and so converting them back and forth\nbetween LF and CRLF is just a waste of time.\n\nThe whole idea behind my suggestion is to minimize confusion.\n"},{"id":"141217","messageId":"AANLkTikbIHfX5pUOn2Yk44IWzqTFDpyapC1V-C-br9jF@mail.gmail.com","threadId":"23705","inReplyTo":"g2h600158c31005071949ve3397f18j3c38017be32dd591@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-08T03:31:04Z","receivedAt":"2010-05-08T03:31:04Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"On Fri, May 7, 2010 at 10:49 PM, hasen j wrote:\n> On 7 May 2010 19:49, Linus Torvalds wrote:\n>>\n>>\n>> Don't be silly.\n>>\n>> The whole AND ONLY point of CRLF translation is that line-endings are\n>> different on different platforms.\n>>\n>>                        Linus\n\nActually, Linus, that depends. And while you will recognize this, let\nme state the obvious, that there are cases where for certain text\nfiles the platform does not matter, that for all platforms they MUST\nnormalize to one setting. For instance there are cases where text\nfiles MUST be LF ended on ALL platforms. Have you considered XML to be\none such example? The W3 XML spec states:\n\n ... [XML processors] MUST behave as if it normalized all line\nbreaks in external parsed entities (including the document entity) on\ninput, before parsing, by translating both the two-character sequence\n#xD #xA and any #xD that is not followed by #xA to a single #xA\ncharacter.\n\nSo here is an example of a text file that by convention MUST be\nLF-based, yes, even on Windows. And for the record, solution (sln)\nfiles have been an XML format for seven years now. So in any one\nworkspace it is entirely reasonable that there may be some text files\nthat MUST have LF, while for other files they SHOULD have CR/LF. There\nare also cases where some text files MUST have CR/LF (some scripting\nlanguages barf on Windows otherwise).\n\n[snip ...]\n\n> The way git handles crlf is just confusing; in fact it's so confusing\n> that it's often better to just turn it off. I'm not the only person\n> who thinks that. It's specifically confusing because git thinks \"if\n> you're on windows then ALL your files should be CRLF\", which is\n> clearly what you think.\n\nHasen makes a good point here. It is simply this, the LF issue does\nnot boil down to a single boolean switch. People who think of the\nLF/CRLF issue as a boolean switch are not dealing with all the facts.\nThere's a lot of grey, not simply black and white.\n\nCommercial systems, decent ones that is, have had this right for years\n(12+ years as I recall). We wouldn't be asking Git to do the right\nthing if we weren't sold on Git already. Git is otherwise fantastic\n(with using it on Windows being the apparent exception, hence this\nconversation).\n\n[snip ...]\n\n> When that happens, it's most likely the case that these files are\n> platform-dependent anyway, and so converting them back and forth\n> between LF and CRLF is just a waste of time.\n\nI disagree on this one actually, this comment is not spot on. Again,\nit depends. I'd generally say,\n\n* perform conversions, or no conversions as the case may be, on the\nobvious file types\n* when conversions occur, normalize internally to only one convention\n* otherwise perform no conversions\n\n> The whole idea behind my suggestion is to minimize confusion.\n\nConfusion, yes. The Git documentation is very confusing on this\npoint... Linus and Junio may want to lift a page from the Perforce\nbook ;)\n\nI would hope that people do agree there is a problem here, that Git\nSHOULD have a good answer to the issue of line feeds. I am no expert\non Git, and I will not pretend to be, but at Iron Mountain we are\nlooking at adopting Git, but this is one of two questions that I have.\nHaving worked with complete pleasure for years with Perforce,\nline-feeds had NEVER been an issue, but the documentation about\nline-feed support in Git seems a bit \"odd\". Mind you, as much as I\nlove Perforce, I also love Git, perhaps more (except for Git on\nWindows). But I am now digress, so back to the point...\n\nBy the way, Linus and Junio, have you read this yet:\n\n* http://kb.perforce.com/?article=063\n\nIt would seem to me there are some text files that by convention MUST\nhave LF regardless of the platform, and there are examples of text\nfiles that MAY have CRLF depending upon the platform.\n\nSo long as an SCM has a provision to permit, whether by prescription\nand/or by convention, various line-feed types, files will naturally\nfall into one of the following three categories:\n\n* normalization to LF on input, preserving otherwise; e.g. XML\n* automatic conversions to platform line feeds for files otherwise\nconsidered ordinary text\n* no conversions for everything else, treated as binary\n\nClassic examples of files that MUST have conversions to platform\nline-feeds are scripts (but not all types of scripts mind you) that\notherwise would not parse properly. I'm sure we've all seen cases of\nthis, especially when copying files from one system type to another\nover a mount. XML-based build environments are particularly\ntroublesome in this regard (e.g. Ant).\n\n- Bob\n"},{"id":"141218","messageId":"n2g32541b131005072034o2bceb6b7h34f68ad5c867eddf@mail.gmail.com","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071847100.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-08T03:34:36Z","receivedAt":"2010-05-08T03:34:36Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 9:49 PM, Linus Torvalds\n wrote:\n> So when you say \"What does the platform care?\", that is a totally idiotic\n> and utterly stupid thing to ask.\n>\n> And since you ask it, I can only assume that you don't understand anything\n> about the whole CRLF discussion, that you don't care about cross-platform\n> repositories, and that as a result you should NEVER EVER actually use any\n> of the git crlf conversion code.\n\nI guess there's your use case for being able to turn off crlf=input, then. :)\n\nHasen: you and Linus don't seem to be communicating clearly, but it\nlooks to me like Linus's proposed changes would work fine for your use\ncase. What you want is for the repository maintainer to be able to\ncontrol whether a file is checked out with crlf or not; this is\npossible with *either* a per-project .gitconfig or a crlf=true\nattribute that works when core.autocrlf is unspecified, which are\nLinus's two suggested options. If you really, truly want your crlf\ncharacters not to be messed with, then set crlf=false, which means\n\"binary.\" [1].\n\n[1] Which reminds me of my opinion about it being too hard to tell\nwhat you're specifying given the current set of config options. But\n'man gitattributes' makes at least this point clear.\n\nHave fun,\n\nAvery\n"},{"id":"141219","messageId":"k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com","threadId":"23705","inReplyTo":"AANLkTikbIHfX5pUOn2Yk44IWzqTFDpyapC1V-C-br9jF@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-08T03:45:39Z","receivedAt":"2010-05-08T03:45:39Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, May 7, 2010 at 11:31 PM, Robert Buck wrote:\n> Actually, Linus, that depends. And while you will recognize this, let\n> me state the obvious, that there are cases where for certain text\n> files the platform does not matter, that for all platforms they MUST\n> normalize to one setting. For instance there are cases where text\n> files MUST be LF ended on ALL platforms. Have you considered XML to be\n> one such example? The W3 XML spec states:\n>\n>   ... [XML processors] MUST behave as if it normalized all line\n> breaks in external parsed entities (including the document entity) on\n> input, before parsing, by translating both the two-character sequence\n> #xD #xA and any #xD that is not followed by #xA to a single #xA\n> character.\n\nErm, this seems to be a counterexample to your point. It says very\nclearly that the files can use either LF or CRLF line endings, and\nwill be parsed correctly either way, or your parser is broken. So\npretty much any CRLF conversion rule (or none at all) will work with\nsuch files.\n\nHasen wrote:\n>> The way git handles crlf is just confusing; in fact it's so confusing\n>> that it's often better to just turn it off.\n\nTrue. This discussion is about fixing that, though, so it seems\nunnecessary to make that point.\n\n> Hasen makes a good point here. It is simply this, the LF issue does\n> not boil down to a single boolean switch. People who think of the\n> LF/CRLF issue as a boolean switch are not dealing with all the facts.\n> There's a lot of grey, not simply black and white.\n\nHow on earth is anyone suggesting that it's a simple boolean switch?\nLinus posted an 8-cell truth table earlier, and he hadn't even\nincluded all the cases.\n\n> I'd generally say,\n>\n> * perform conversions, or no conversions as the case may be, on the\n> obvious file types\n> * when conversions occur, normalize internally to only one convention\n> * otherwise perform no conversions\n\nUnfortunately those steps aren't clear enough to be helpful. \"as the\ncase may be\" and \"obvious file types\" are definitely not obvious, or\nwe wouldn't be here.\n\n> Confusion, yes. The Git documentation is very confusing on this\n> point... Linus and Junio may want to lift a page from the Perforce\n> book ;)\n\nI've learned that git people never learn from anyone's book. svn has\nalso had this problem solved pretty much forever, and would be easy to\ncopy. For better or for worse, it all has to be hashed out from\nscratch or it won't happen.\n\n> It would seem to me there are some text files that by convention MUST\n> have LF regardless of the platform, and there are examples of text\n> files that MAY have CRLF depending upon the platform.\n\nWell... obviously. The former case is crlf=false; the latter is\ncrlf=true. To bring up my point again about the confusing\nconfiguration options, you might think that \"crlf=true\" means \"always\nCRLF\", but in fact that's not the case. In fact it works the way you\nwant.\n\nHave fun,\n\nAvery\n"},{"id":"141242","messageId":"q2q600158c31005080336u1d1b8b78n3dc7ad0055b99119@mail.gmail.com","threadId":"23705","inReplyTo":"k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"hasen j","fromEmail":"hasan.aljudy@gmail.com","sentAt":"2010-05-08T10:36:05Z","receivedAt":"2010-05-08T10:36:05Z","isPatch":true,"sender":{"key":"hasan.aljudy@gmail.com","avatar":"https://gravatar.com/avatar/47314b4bfcc6ba6685a811d9697fe60e90602acec0e24b9bf48bd0a97307f7c2?d=mp&s=160"},"body":">\n> It's that simple. You seem to totally miss the whole point of the whole\n> feature in the first place.\n>\n> Linus\n\nSure, I won't deny, it always baffled me why it's built into git.\n\nThe only good reason I could think of is avoiding scenarios someone\nsaves a file with different line endings and then all merging hell\nwould break loose because all lines are changed. Although\ntheoretically I think that can be avoided if the merge algorithm\nnormalized line endings before the merge (but really, I don't know\nanything about merging).\n\nUnder this assumption, the point of autocrlf is that windows users\nshould commit with LF endings even if they use CRLF in the working\ndirectory (e.g. some stupid text editor resaves files with crlf).\n\nIf that's not the reason, then why the hell does git care about\nconverting line ending styles?\n\nIf the only reason is \"LF is not a new line in Windows\", then I'll go\nback to my previous opinion that autocrlf is useless most of the time\nand shouldn't be builtin; use smudge/clean filters instead if you\nreally need crlf files.\n\n\n\n>>   ... [XML processors] MUST behave as if it normalized all line\n>> breaks in external parsed entities (including the document entity) on\n>> input, before parsing, by translating both the two-character sequence\n>> #xD #xA and any #xD that is not followed by #xA to a single #xA\n>> character.\n>\n> Erm, this seems to be a counterexample to your point.  It says very\n> clearly that the files can use either LF or CRLF line endings, and\n> will be parsed correctly either way, or your parser is broken.  So\n> pretty much any CRLF conversion rule (or none at all) will work with\n> such files.\n\nAgreed. This is an example where all line endings are valid on all platforms.\n\n>\n> Hasen wrote:\n>>> The way git handles crlf is just confusing; in fact it's so confusing\n>>> that it's often better to just turn it off.\n>\n> True.  This discussion is about fixing that, though, so it seems\n> unnecessary to make that point.\n\nIt is necessary. It's broken because the assumptions it's built on are wrong.\n\n>> Hasen makes a good point here. It is simply this, the LF issue does\n>> not boil down to a single boolean switch. People who think of the\n>> LF/CRLF issue as a boolean switch are not dealing with all the facts.\n>> There's a lot of grey, not simply black and white.\n>\n> How on earth is anyone suggesting that it's a simple boolean switch?\n> Linus posted an 8-cell truth table earlier, and he hadn't even\n> included all the cases.\n\nThat's cool and all, but we need to simplify it; not make it more\nconfusing. The name autocrlf is confusing all by itself: what does it\nmean? is it a two way conversion or a one way conversion? Where the\nhell did \"input\" come from? I always have to pull up the man pages.\n\nI'd rather be able to say:\n\n- My over all preference is 'lf'\n- For this repo, this file here is always 'lf' (takes precedence over\nthe above preference)\n- And this other file here is always 'crlf' (ditto)\n\nThis model makes way more sense for me as a user and for the project.\n\n\n>> Confusion, yes. The Git documentation is very confusing on this\n>> point... Linus and Junio may want to lift a page from the Perforce\n>> book ;)\n>\n> I've learned that git people never learn from anyone's book.  svn has\n> also had this problem solved pretty much forever, and would be easy to\n> copy.  For better or for worse, it all has to be hashed out from\n> scratch or it won't happen.\n\nNo, I actually think git got source control right exactly because it\ndidn't bother copying other existing systems. The other system's\nsolutions don't necessarily fit with git's model.\n"},{"id":"141246","messageId":"AANLkTimtBLWaTnCx5wcivLpVfbF-hREsZnJCayCWcJV7@mail.gmail.com","threadId":"23705","inReplyTo":"k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-08T11:36:43Z","receivedAt":"2010-05-08T11:36:43Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"[...]\n\n>> character.\n>\n> Erm, this seems to be a counterexample to your point.  It says very\n> clearly that the files can use either LF or CRLF line endings, and\n> will be parsed correctly either way, or your parser is broken.  So\n> pretty much any CRLF conversion rule (or none at all) will work with\n> such files.\n\nPerhaps I was not clear, or you did not understand my point.\n\nRead \"...by translating... to #xA\", XSLT output to a file therefore\nMUST be LF by definition for it to be canonical form. This is an\nexample of a TEXT file that MUST by definition of the spec be LF based\non all platforms. Looking at the \"auto\" code that exists in Git, it\ndoes not appear to support this very obvious standard, whereby for\nthis \"file-type\" it should always be checked out of source control\nwith LF regardless of how it came in. This is equivalent to the Git\n\"input\" setting I believe (?), but on a file-type basis. Yes, Git\napparently does not have the notion of file-types, does it (e.g. *.xml\nmaps to text)?\n\nThe point I am really trying to make clear is that there are multiple\ndimensions to this problem, and not making that succinct will result\nin a botched attempt. We need to carefully distinguish file-types from\nother switches that control whether or not to perform automatic\nconversions. The two dimensions are eol-style and file-type.\n\nTHE SWITCHES\n\nSo for the switches, here is what would be meaningful to me, short, sweet:\n\ncore.autocrlf :: true false\ncore.eolstyle :: local share lf crlf\n\nIf autocrlf is false, then what comes out is exactly what goes in.\n\nEOL-STYLE\n\nThe eolstyle property only applies to text files (discussed later):\n\n- \"local\" means normalize \"text\" files to LF when read in, and convert\nto the platform preferred setting when materializing workspaces.\n- \"share\" means accept anything, but when writing files to a workspace\nnormalize to LF (XML, XSLT, some scripting languages ...)\n- \"lf\" means always to accept anything though and convert to LF, output LF\n- \"crlf\" means to accept anything and convert to CRLF on output\n\nFILE-TYPES\n\nLinus alluded above file-types, and being explicit about them. That's\ngreat, I agree. Let me provide examples:\n\nBy extension:\n http://www.perforce.com/perforce/doc.current/manuals/cmdref/o.ftypes.html\n\nBy pathnames or extensions:\n http://www.perforce.com/perforce/doc.current/manuals/cmdref/typemap.html\n\nDon't beat me up for referencing other systems, please. But as people\nmove to Git from other systems there will be some level of\nexpectation, so understanding those perspectives and expectations so\nyou are prepared to provide a meaningful answer would help.\n\nAUTO/TEXT-DETECTION\n\nSo the above explicit definitions gets you most of the way, but what\nabout \"auto\"? This is a question at the heart of convert.c, the\ngather_stats function that classifies among other things whether or\nnot an input is text or binary.\n\nWhile gather_stats is a good start, it naively is US-centric; it most\nassuredly does not address UTF-8 and ISO-8859-1, both of which are\nVERY easy to identify, but are not presently handled by this\nalgorithm. I wrote a simple stat gatherer for the MATLAB kernel years\nago that classified the character-set of arbitrary input text to one\nof about a half-dozen common character-sets, so what about adding in a\nlightweight checker for at least UTF-8 and ISO-8859-1? I could provide\nsuch a thing back to this community if people wish.\n\nTo have a little more in the gather_stats code to handle a couple more\ncases would go a long way and would be easy to add, and does not\nnecessarily depend up file-type support. It would simply broaden what\nit means to be a text file.\n"},{"id":"141260","messageId":"20100508204934.GA25566@dpotapov.dyndns.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-08T20:49:34Z","receivedAt":"2010-05-08T20:49:34Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, May 07, 2010 at 02:54:40PM -0700, Linus Torvalds wrote:\n> \n> (a) you should try to avoid do things like that in the first place. For \n> something like an attribute file, you should just list the files you \n> want to convert. That's the _point_ of an attribute. So it's much \n> nicer if you instead actually are explicit about it, ie\n> \n> \t*.[ch] crlf\n> \t*.txt crlf\n> \t*.jpg -crlf\n> \n> should be the _primary_ way you do it, since the autocrlf thing is a \n> bit dangerous in theory.\n> \n> (b) But let's say that you want to do it anyway (because you're lazy \n> and because autocrlf works pretty damn well in practice), isn't that \n> a really ugly and crazy thing to add _another_ attribute name for \n> that?\n> \n> IOW, if you really want to say \"do automatic crlf for this set of \n> paths\", the natural syntax for that would be\n> \n> \t* crlf=auto\n> \n> No? Not some totally new attribute name.\n\nI like your proposal and it makes perfect sense to me, but I am not new\nto git and core.autocrlf. I have observed that many people who were new\nto Git often got confused by meaning of the crlf attribute. In essence,\nat first, they thought that it means what you would probably describe as\ncrlf=force. Thus, seeing something like this:\n\n *.sln -crlf\n\nbaffled them, because sln files have CRLF as ending. So, it was very\ncounter-intuitive for them. Of course, you can explain that Git stores\ntext files with LF internally, and why it is the sane thing to do, and\nwhy sln files are not exactly text files (at least, non-text in sense\nof eol-conversion), etc... but I believe that all those discussion and\nexplanation could be easily avoided by renaming 'crlf' as 'eol'. Now,\nif you look at this:\n\n *.sln -eol\n *.jpg -eol\n *.txt eol\n *.[ch] eol\n\nit is clear that .sln and .jpg files are stored \"as is\", while Git does\nthe end-of-line conversion for others files in accordance with user's\npreference. Why should users bother at all how Git stores text files\ninternally? They do not need to know that Git stores text files with LF\ninternally. They just want to checkout those files with the right ending\nfor their platform.\n\nSo, perhaps, 'eol' would be a better name than 'crlf' for new Git users.\n\n\n\nDmitry\n"},{"id":"141267","messageId":"alpine.LFD.2.00.1005081450260.3711@i5.linux-foundation.org","threadId":"23705","inReplyTo":"20100508204934.GA25566@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-08T21:54:35Z","receivedAt":"2010-05-08T21:54:35Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 May 2010, Dmitry Potapov wrote:\n>\n> explanation could be easily avoided by renaming 'crlf' as 'eol'.\n\nWhat the heck is wrong with people?\n\n> Now, if you look at this:\n> \n> *.sln -eol\n> *.jpg -eol\n> *.txt eol\n> *.[ch] eol\n\nRight. Look at it. It's totally incomprehensible. It's _worse_ than \"crlf\" \nas a name.\n\nWhat the f*ck does \"jpg\" have to do with \"eol\"? Nothing.\n\nYou could talk about \"binary\" vs \"text\", and it would make sense, but your \nargument that \"eol\" is somehow better than \"crlf\" is just insane.\n\nSo I could certainly see\n\n\t*.jpg binary\n\t*.txt text\n\nmaking sense. But \"eol\" is certainly no better than \"crlf\". \n\nIn the end, crlf is what we have. We're not getting rid of it, so if \nsomebody were to actually rename it, that would just mean that there are \n_two_ different ways to say the same thing. And quite frankly, I think \nthat's worse than what we have now, so I don't think it's worth it.\n\n\t\tLinus\n"},{"id":"141275","messageId":"20100508234222.GA14069@dpotapov.dyndns.org","threadId":"23705","inReplyTo":"alpine.LFD.2.00.1005081450260.3711@i5.linux-foundation.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-08T23:42:22Z","receivedAt":"2010-05-08T23:42:22Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, May 08, 2010 at 02:54:35PM -0700, Linus Torvalds wrote:\n> \n> \n> On Sun, 9 May 2010, Dmitry Potapov wrote:\n> >\n> > explanation could be easily avoided by renaming 'crlf' as 'eol'.\n> \n> What the heck is wrong with people?\n> \n> > Now, if you look at this:\n> > \n> > *.sln -eol\n> > *.jpg -eol\n> > *.txt eol\n> > *.[ch] eol\n> \n> Right. Look at it. It's totally incomprehensible. It's _worse_ than \"crlf\" \n> as a name.\n> \n> What the f*ck does \"jpg\" have to do with \"eol\"? Nothing.\n\nRight, nothing, in other words, no eol conversion... and \"-eol\" seems to\nexpress this idea well. So, I don't see why it is worse than \"crlf\"...\n\nPersonally, I do not care whether it is \"crlf\", or \"eol\", but a lot of\npeople that I know were confused by crlf, because they thought that it\nmeans that this file is stored with crlf, while this attribute actually\nmeans that file needs eol conversion.\n\n> \n> You could talk about \"binary\" vs \"text\", and it would make sense, but your \n> argument that \"eol\" is somehow better than \"crlf\" is just insane.\n> \n> So I could certainly see\n> \n> \t*.jpg binary\n> \t*.txt text\n> \n> making sense. But \"eol\" is certainly no better than \"crlf\". \n\nWhat about .sln files? They are xml files with CRLF ending. Does it mean\nthey are binary? Based on how it is stored, it is certainly binary, but\nwhen it comes to \"diff\" or even \"merge\" you may want to think about them\nas text, and, in general, people tend to think about them as text files.\n\nAnother example is shell scripts. You really want them to be LF even on\nWindows. So, is it a binary file too?\n\nSo, this approach is not so intuitive as it may appear if you consider\nonly .jpg and .txt.\n\n> \n> In the end, crlf is what we have. We're not getting rid of it, so if \n> somebody were to actually rename it, that would just mean that there are \n> _two_ different ways to say the same thing. And quite frankly, I think \n> that's worse than what we have now, so I don't think it's worth it.\n\nI was not sure myself that the idea of renaming worth it... While I do\nthink that \"eol\" is a better name than \"crlf\", but not by big margin,\nand as you said crlf is what we have now... so be it...\n\n\nDmitry\n"},{"id":"141297","messageId":"42C31791-ACD3-4D43-99E6-287F9E63EDAB@gmail.com","threadId":"23705","inReplyTo":"20100508234222.GA14069@dpotapov.dyndns.org","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-05-09T07:49:03Z","receivedAt":"2010-05-09T07:49:03Z","isPatch":true,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 9. mai 2010, at 01.42, Dmitry Potapov wrote:\n\n> On Sat, May 08, 2010 at 02:54:35PM -0700, Linus Torvalds wrote:\n\n[...]\n\n>> You could talk about \"binary\" vs \"text\", and it would make sense, but your \n>> argument that \"eol\" is somehow better than \"crlf\" is just insane.\n>> \n>> So I could certainly see\n>> \n>> \t*.jpg binary\n>> \t*.txt text\n>> \n>> making sense. But \"eol\" is certainly no better than \"crlf\". \n> \n> What about .sln files? They are xml files with CRLF ending. Does it mean\n> they are binary? Based on how it is stored, it is certainly binary, but\n> when it comes to \"diff\" or even \"merge\" you may want to think about them\n> as text, and, in general, people tend to think about them as text files.\n> \n> Another example is shell scripts. You really want them to be LF even on\n> Windows. So, is it a binary file too?\n\nI think \"binary\" and \"text\" are the wrong things to talk about in this case.\n\nIf we were to following Avery's suggestion that we look at what we would have implemented had autocrlf not already existed, it would be better to call \"crlf\" something like \"eolconv\". You're not saying that a file is text or binary as such, rather that \"I want eol conversion for this file\" or \"I don't want eol conversion for this file\".\n\nFlagging a file as \"-eolconv\" because it should always have LFs or always CRLFs seems logical to me. \"eolconv=auto\" also makes sense.\n\n[...]\n\n>> In the end, crlf is what we have. We're not getting rid of it, so if \n>> somebody were to actually rename it, that would just mean that there are \n>> _two_ different ways to say the same thing. And quite frankly, I think \n>> that's worse than what we have now, so I don't think it's worth it.\n> \n> I was not sure myself that the idea of renaming worth it... While I do\n> think that \"eol\" is a better name than \"crlf\", but not by big margin,\n> and as you said crlf is what we have now... so be it...\n\nRenaming \"crlf\" might not be worth it, but thinking about what it should look like definitely is worth it. Since I already have a patch series that changes this area, I'd like for it to be future proof.\n\nI think the idea that we're stuck with \"crlf\" (or any bad ui design) for ever and ever is depressing, and I reject it. It would be easy to create a new attribute with a better name that is the same setting under the hood, and deprecate \"crlf\". The old attribute would still work in existing repositories (indefinitely, if needs be), but new users wouldn't have to be confused by its poor name.\n\nI'm not saying I want to replace \"crlf\" right now! I'm just saying that it makes sense to think about how we would want to replace it, and try not to introduce any new change that will make it harder to do the right thing later.\n-- \nEyvind\n"},{"id":"141306","messageId":"AANLkTimDIPJpwpAJPTBIYK6QLwfBBpYP0w2RTvKbRys5@mail.gmail.com","threadId":"23705","inReplyTo":"42C31791-ACD3-4D43-99E6-287F9E63EDAB@gmail.com","subject":"Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-05-09T10:35:27Z","receivedAt":"2010-05-09T10:35:27Z","isPatch":true,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"On Sun, May 9, 2010 at 3:49 AM, Eyvind Bernhardsen\n wrote:\n> On 9. mai 2010, at 01.42, Dmitry Potapov wrote:\n>\n>> On Sat, May 08, 2010 at 02:54:35PM -0700, Linus Torvalds wrote:\n>\n> [...]\n>\n>>> You could talk about \"binary\" vs \"text\", and it would make sense, but your\n>>> argument that \"eol\" is somehow better than \"crlf\" is just insane.\n>>>\n>>> So I could certainly see\n>>>\n>>>      *.jpg binary\n>>>      *.txt text\n>>>\n>>> making sense. But \"eol\" is certainly no better than \"crlf\".\n\nLinus - Perhaps I missed this, but where would you this typemap exist?\nI like this sort of prescriptive approach; out of the box users would\nget a bunch of reasonable defaults, but they could customize it by\nadding/changing them.\n"},{"id":"141864","messageId":"U4$sctFu6q8LFwWA@thewolery.demon.co.uk","threadId":"23705","inReplyTo":"o2v40aa078e1005061625md5fede79h660a22227c4f22d1@mail.gmail.com","subject":"Re: What should be the CRLF policy when win + Linux?","fromName":"Anthony W. Youngman","fromEmail":"wol@thewolery.demon.co.uk","sentAt":"2010-05-18T15:13:50Z","receivedAt":"2010-05-18T15:13:50Z","isPatch":false,"sender":{"key":"wol@thewolery.demon.co.uk","avatar":null},"body":"In message \n, Erik \nFaye-Lund writes\n>Closed source does not imply a single operating system, and you get\n>these issues whenever you have a project with targets systems with\n>different newline style. In my day job I develop closed source,\n>multi-platform software, using git. So it's certainly not MY most\n>common scenario.\n\nAnd there's a lot more line endings out there than just lf or crlf.\n\nOkay, the two I'm about to quote have, I believe, gone the way of the \ndinosaur, but wasn't the mac just cr? And what is *still* my favourite \nsystem, Prime (a multics derivative too), used a \"packed lf\", so your \nline ending could be either lf or lfnull depending on the line length \n(it was always stored on disk as an integral word-length, a word being \n16 bits. So if your text was an even number of characters, the ending \nwas lfnull to pad it to the next word boundary).\n\nCheers,\nWol\n-- \nAnthony W. Youngman - anthony@thewolery.demon.co.uk\n"}]}