{"thread":{"id":"16580","subject":"Buggy (or undocumented) handling of terminal \\r in .gitignore patterns","startedAt":"2008-12-03T15:46:31Z","lastAt":"2008-12-03T17:42:11Z","messageCount":2,"participants":["Aaron Harnly","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97073","messageId":"loom.20081203T152511-351@post.gmane.org","threadId":"16580","inReplyTo":null,"subject":"Buggy (or undocumented) handling of terminal \\r in .gitignore patterns","fromName":"Aaron Harnly","fromEmail":"git@lists.harnly.net","sentAt":"2008-12-03T15:46:31Z","receivedAt":"2008-12-03T15:46:31Z","isPatch":false,"sender":{"key":"git@lists.harnly.net","avatar":null},"body":"This is with git 1.5.6.3 on Ubuntu and Mac OS X.\n\nOverview: .gitignore patterns ending in \\r do not work as expected, apparently\nbecause the terminal \\r is assumed to be part of the newline.\n\nSteps to Reproduce:\n(NB ^M is the control-M sequence, not a literal caret-M)\n\n1. Create an empty repository.\n2. Create a file named Icon\\r (aka Icon^M).\n3. Add the following pattern to the .gitignore:\n\nIcon^M\n\nExpected behavior:\n\nThe file is ignored.\n\nActual behavior:\n\nThe file is not ignored.\n\nDiscussion:\n\nIt appears that the parsing of .gitignore files tries to be graceful in allowing\nthe file to have CRLF endings, or indeed mixed LF / CRLF endings.\n\nThis is well and good, but poses a bit of a problem for ignoring files whose\nname ends in \\r. In particular, Mac OS X's icon files are named Icon\\r. Yes,\nthis is sick and annoying on the part of Apple.\n\nI understand the rationale for this behavior, but it probably should be\ndocumented somewhere. In the meantime, a workaround that does allow the ignoring\nof these files is the pattern:\n\nIcon^M^M\n\nwhere again, the terminal \\r seems to be ignored as part of the newline, but the\npenultimate \\r gets picked up as part of the pattern.\n\nAny thoughts on whether:\n1. this behavior should be left as it is\n2. there is actually documentation somewhere that I didn't see\n3. terminal \\r in an otherwise all-LF file should be assumed to be part of the\npattern\n4. some other alternative?\n\ncheers,\n~aaron\n"},{"id":"97080","messageId":"4936C4F3.70501@drmicha.warpmail.net","threadId":"16580","inReplyTo":"loom.20081203T152511-351@post.gmane.org","subject":"Re: Buggy (or undocumented) handling of terminal \\r in .gitignore patterns","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-12-03T17:42:11Z","receivedAt":"2008-12-03T17:42:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Aaron Harnly venit, vidit, dixit 03.12.2008 16:46:\n> This is with git 1.5.6.3 on Ubuntu and Mac OS X.\n> \n> Overview: .gitignore patterns ending in \\r do not work as expected, apparently\n> because the terminal \\r is assumed to be part of the newline.\n> \n> Steps to Reproduce:\n> (NB ^M is the control-M sequence, not a literal caret-M)\n> \n> 1. Create an empty repository.\n> 2. Create a file named Icon\\r (aka Icon^M).\n> 3. Add the following pattern to the .gitignore:\n> \n> Icon^M\n> \n> Expected behavior:\n> \n> The file is ignored.\n> \n> Actual behavior:\n> \n> The file is not ignored.\n> \n> Discussion:\n> \n> It appears that the parsing of .gitignore files tries to be graceful in allowing\n> the file to have CRLF endings, or indeed mixed LF / CRLF endings.\n> \n> This is well and good, but poses a bit of a problem for ignoring files whose\n> name ends in \\r. In particular, Mac OS X's icon files are named Icon\\r. Yes,\n> this is sick and annoying on the part of Apple.\n> \n> I understand the rationale for this behavior, but it probably should be\n> documented somewhere. In the meantime, a workaround that does allow the ignoring\n> of these files is the pattern:\n> \n> Icon^M^M\n> \n> where again, the terminal \\r seems to be ignored as part of the newline, but the\n> penultimate \\r gets picked up as part of the pattern.\n> \n> Any thoughts on whether:\n> 1. this behavior should be left as it is\n> 2. there is actually documentation somewhere that I didn't see\n> 3. terminal \\r in an otherwise all-LF file should be assumed to be part of the\n> pattern\n> 4. some other alternative?\n\n5. spank Apple\n"}]}