{"thread":{"id":"25061","subject":"possible gitattributes eol bug with new eol=crlf | lf support?","startedAt":"2010-09-09T22:31:31Z","lastAt":"2010-09-13T19:49:45Z","messageCount":6,"participants":["Robert Buck","Eyvind Bernhardsen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150416","messageId":"AANLkTinC8g9m=2ka=7LiHH4MtfxC-NbxbsYQEbmMyXmN@mail.gmail.com","threadId":"25061","inReplyTo":null,"subject":"possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-09-09T22:31:31Z","receivedAt":"2010-09-09T22:31:31Z","isPatch":false,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"I start with a repository containing only four files:\n\n  * lf.xml\n  * lf.sln\n  * crlf.xml\n  * crlf.sln\n\nThe files whose names are prefixed by LF contain Unix LF EOL\ncharacters. The files whose names are prefixed by CRLF contain Windows\nCRLF EOL characters. Each file contains two lines, on one line 'jim',\nthe second line contains 'tim'.\n\nI later add and commit a .gitattributes file containing the following rules:\n\n  *.sln  eol=crlf\n  *.xml eol=lf\n\nI _then_ clone the repository and open each file in binary mode to find:\n\n  * the crlf.xml file contains CRLF when it should contain only LF\n<<<<<<< BUG ???\n  * the crlf.sln file contains CRLF as it rightly should\n  * the lf.xml file contains LF as it rightly should\n  * the lf.sln file contains CRLF as it rightly should\n\nConversion of LF-EOL files to CRLF works fine, but conversion of CRLF\nto LF fails to occur.\n\nThe doc is a little unclear if this is expected behavior, which if I\nrecall correctly from the email threads related to the new eol\nsupport, this should not have occurred.\n\nGuidance appreciated.\n"},{"id":"150457","messageId":"1F2D74A7-1C9C-47D9-9C3D-E430E446CB94@gmail.com","threadId":"25061","inReplyTo":"AANLkTinC8g9m=2ka=7LiHH4MtfxC-NbxbsYQEbmMyXmN@mail.gmail.com","subject":"Re: possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-09-10T18:25:58Z","receivedAt":"2010-09-10T18:25:58Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 10. sep. 2010, at 00.31, Robert Buck wrote:\n\n[...]\n\n> Conversion of LF-EOL files to CRLF works fine, but conversion of CRLF\n> to LF fails to occur.\n> \n> The doc is a little unclear if this is expected behavior, which if I\n> recall correctly from the email threads related to the new eol\n> support, this should not have occurred.\n\nUnfortunately, this is expected behaviour: you need to \"manually\" remove CRLFs when you turn on eol conversion.  The simplest way to do this is \"rm .git/index && git reset\", then commit the modified files (ideally in the same commit that modifies .gitattributes--this is mentioned in gitattributes(5)).\n\nTo make this work as it should, git would have to notice changes to .gitattributes and check files which have had their attributes changed.  It's on my \"I wish I had time to do this\" list.\n\n- Eyvind\n"},{"id":"150477","messageId":"AANLkTi=xPpPZzUqVEHEkH2sKvSVZH+MzunET6vEA_tw5@mail.gmail.com","threadId":"25061","inReplyTo":"1F2D74A7-1C9C-47D9-9C3D-E430E446CB94@gmail.com","subject":"Re: possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-09-10T21:27:13Z","receivedAt":"2010-09-10T21:27:13Z","isPatch":false,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"I don't understand the inner workings of .git/index, but is removing\nthat file destructive to history or anything? What are the\nimplications of that delete-command?\n\nBob\n\nOn Fri, Sep 10, 2010 at 2:25 PM, Eyvind Bernhardsen\n<eyvind.bernhardsen@gmail.com> wrote:\n> On 10. sep. 2010, at 00.31, Robert Buck wrote:\n>\n> [...]\n>\n>> Conversion of LF-EOL files to CRLF works fine, but conversion of CRLF\n>> to LF fails to occur.\n>>\n>> The doc is a little unclear if this is expected behavior, which if I\n>> recall correctly from the email threads related to the new eol\n>> support, this should not have occurred.\n>\n> Unfortunately, this is expected behaviour: you need to \"manually\" remove CRLFs when you turn on eol conversion.  The simplest way to do this is \"rm .git/index && git reset\", then commit the modified files (ideally in the same commit that modifies .gitattributes--this is mentioned in gitattributes(5)).\n>\n> To make this work as it should, git would have to notice changes to .gitattributes and check files which have had their attributes changed.  It's on my \"I wish I had time to do this\" list.\n>\n> - Eyvind\n>\n>\n"},{"id":"150534","messageId":"4F27AD7B-2B2D-4378-B1D5-6F380396E0FF@gmail.com","threadId":"25061","inReplyTo":"AANLkTi=xPpPZzUqVEHEkH2sKvSVZH+MzunET6vEA_tw5@mail.gmail.com","subject":"Re: possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-09-12T11:46:32Z","receivedAt":"2010-09-12T11:46:32Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 10. sep. 2010, at 23.27, Robert Buck wrote:\n\n> I don't understand the inner workings of .git/index, but is removing\n> that file destructive to history or anything? What are the\n> implications of that delete-command?\n\nRemoving the index will lose the changes you've staged (\"git add\"ed) for the next commit, but your working directory won't be touched.  If you've added a file and then modified or deleted it, you would lose the version of that file that was in the index.\n\n\"git reset\" then rebuilds the index identically to the HEAD commit, but without the staged changes and (importantly) the stat cache.  The point is to make git re-check every file to see if it has been modified.\n\nSorry, I should have mentioned the downsides.\n\n- Eyvind\n"},{"id":"150549","messageId":"AANLkTi=9Wv9_s2zDEdpc8Dn7qXSRepZSToKkOrAoTQnR@mail.gmail.com","threadId":"25061","inReplyTo":"4F27AD7B-2B2D-4378-B1D5-6F380396E0FF@gmail.com","subject":"Re: possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Robert Buck","fromEmail":"buck.robert.j@gmail.com","sentAt":"2010-09-12T19:58:43Z","receivedAt":"2010-09-12T19:58:43Z","isPatch":false,"sender":{"key":"buck.robert.j@gmail.com","avatar":"https://gravatar.com/avatar/1686742e8ac2595378aac67f26fd638ddaf494194f9af0cb6082c4a7eca1a366?d=mp&s=160"},"body":"Thanks Eyvind,\n\nI tried it on an experimental repository and it worked. Thank you for\nyour recommendation.\n\nI also found the following link at github which achieves a similar\neffect. Adding this for the record in case someone else searching for\na solution in the future wanted more detail.\n\n    http://help.github.com/dealing-with-lineendings/\n\nThe one thing I find curious about the github article is that it seems\nto recommend using autocrlf=true for ALL platforms once the linefeeds\nhave been normalized.\n\nLet me ask for an opinion about this... Given we have an environment\nof mixed Windows, Mac, and Linux developers, that we have just\nmigrated from svn and over 2000 files in the repository have messed up\nline-endings, what would be your recommendation for autocrlf settings?\nOh, important note, because neither cygwin nor msysgit support newer\nversions of git, we do not have the flexibility of running your new\n\"eol\" support on Windows, while Linux developers do.\n\nSo if we did this one-time normalization on all repositories, all\nbranches, what holistic approach (eol, autocrlf) would keep our files\nsane for a mix of 1.7.2 and later, and 1.7.0.1 and earlier, Windows,\nMac, and Linux?\n\nThanks Eyvind.\n\n-Bob\n\nOn Sun, Sep 12, 2010 at 7:46 AM, Eyvind Bernhardsen\n<eyvind.bernhardsen@gmail.com> wrote:\n> On 10. sep. 2010, at 23.27, Robert Buck wrote:\n>\n>> I don't understand the inner workings of .git/index, but is removing\n>> that file destructive to history or anything? What are the\n>> implications of that delete-command?\n>\n> Removing the index will lose the changes you've staged (\"git add\"ed) for the next commit, but your working directory won't be touched.  If you've added a file and then modified or deleted it, you would lose the version of that file that was in the index.\n>\n> \"git reset\" then rebuilds the index identically to the HEAD commit, but without the staged changes and (importantly) the stat cache.  The point is to make git re-check every file to see if it has been modified.\n>\n> Sorry, I should have mentioned the downsides.\n>\n> - Eyvind\n>\n>\n"},{"id":"150627","messageId":"EBF8B701-6DD6-4D7A-AE2D-49561B4FD7C6@gmail.com","threadId":"25061","inReplyTo":"AANLkTi=9Wv9_s2zDEdpc8Dn7qXSRepZSToKkOrAoTQnR@mail.gmail.com","subject":"Re: possible gitattributes eol bug with new eol=crlf | lf support?","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind.bernhardsen@gmail.com","sentAt":"2010-09-13T19:49:45Z","receivedAt":"2010-09-13T19:49:45Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 12. sep. 2010, at 21.58, Robert Buck wrote:\n\n> Thanks Eyvind,\n> \n> I tried it on an experimental repository and it worked. Thank you for\n> your recommendation.\n\nGreat :)\n\n> I also found the following link at github which achieves a similar\n> effect. Adding this for the record in case someone else searching for\n> a solution in the future wanted more detail.\n> \n>    http://help.github.com/dealing-with-lineendings/\n> \n> The one thing I find curious about the github article is that it seems\n> to recommend using autocrlf=true for ALL platforms once the linefeeds\n> have been normalized.\n\nThat article hasn't been updated for 1.7.2, but what it's saying is that line ending normalisation should be enabled for all users (or none) if you want to avoid problems.\n\nThe point of the text attribute is to allow you to enable or disable line ending normalisation without the user having to configure anything; setting the attribute \"text=auto\" on all files is equivalent to every user manually setting autocrlf to \"true\" or \"input\" in that repository.\n\n[...]\n\n> So if we did this one-time normalization on all repositories, all\n> branches, what holistic approach (eol, autocrlf) would keep our files\n> sane for a mix of 1.7.2 and later, and 1.7.0.1 and earlier, Windows,\n> Mac, and Linux?\n\nI would set the text attribute to auto for all files (add the line \"* text=auto\" to .gitattributes) to take care of users with git 1.7.2 or newer.  Users with older versions of git should set autocrlf=true (Windows) or autocrlf=input (Mac and Linux).\n\nOnce all users are upgraded to newer versions of git you can change the normalisation to target only specific files or file types, but that's not advisable while any of your users have autocrlf enabled.\n\n- Eyvind\n"}]}