{"thread":{"id":"9826","subject":".git/info/exclude w/ CFLF fails in cygwin","startedAt":"2007-09-08T01:01:39Z","lastAt":"2007-09-08T10:36:03Z","messageCount":2,"participants":["Jing Xue","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52966","messageId":"20070908010139.GA5501@falcon.digizenstudio.com","threadId":"9826","inReplyTo":null,"subject":".git/info/exclude w/ CFLF fails in cygwin","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-09-08T01:01:39Z","receivedAt":"2007-09-08T01:01:39Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"(1.5.3.1 in cygwin, Win XP)\nI have cygwin configured to operate in the DOS/text mode, which means\ncygwin translates LF to CRLF when writing a file, and CRLF to LF when\nreading.  Unfortunately cygwin's fstat() implementation doesn't take the\nmode into account when reporting stat.st_size, presumably for the sake\nof performance, while read() does actually do the conversion.\n\nThat causes the function add_excludes_from_file_1() in dir.c to reject a\n.git/info/exclude file with CRLF ending, because the size actually read\nis not the same as the size reported by fstat().\n\nThe simplest fix I have found is to explicitly open the exclude file in\nbinary mode, because the rest of the exclude file parsing code actually\ndeals with CRLF quite fine.\n\nI would submit a patch but I am not sure if this is the appropriate fix.\n\nBy the way, parsing .git/config with CRLF in the same environment works\nfine because the code reads the file by byte and doesn't do any size\nvalidation.\n\nAny thoughts?\n-- \nJing Xue\n"},{"id":"52988","messageId":"200709081236.04411.robin.rosenberg.lists@dewire.com","threadId":"9826","inReplyTo":"20070908010139.GA5501@falcon.digizenstudio.com","subject":"Re: .git/info/exclude w/ CFLF fails in cygwin","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-09-08T10:36:03Z","receivedAt":"2007-09-08T10:36:03Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 08 september 2007 skrev Jing Xue:\n> (1.5.3.1 in cygwin, Win XP)\n> I have cygwin configured to operate in the DOS/text mode, which means\n> cygwin translates LF to CRLF when writing a file, and CRLF to LF when\n> reading.  Unfortunately cygwin's fstat() implementation doesn't take the\n> mode into account when reporting stat.st_size, presumably for the sake\n> of performance, while read() does actually do the conversion.\n\nThis is not just cygwin and applies to all CRLF environments.\n\n> That causes the function add_excludes_from_file_1() in dir.c to reject a\n> .git/info/exclude file with CRLF ending, because the size actually read\n> is not the same as the size reported by fstat().\n\n> The simplest fix I have found is to explicitly open the exclude file in\n> binary mode, because the rest of the exclude file parsing code actually\n> deals with CRLF quite fine.\n> \n> I would submit a patch but I am not sure if this is the appropriate fix.\ndoubt it is worth it..\n> \n> By the way, parsing .git/config with CRLF in the same environment works\n> fine because the code reads the file by byte and doesn't do any size\n> validation.\n> \n> Any thoughts?\n\nI have cygwin in CRLF mode too, but I have binary-mounted the paths' where\nI use git to avoid the problem. I did a half-hearted attempt to fix git in CRLF mode,\nbut it failed because in some places plumbing commands communicate via files\nand in other pipes are used making it hard to get then right translation mode.\n\nThat is not to say it is impossible, but as I understand it the Cygwin project have\nessentially given up on CRLF mode, so it will probably go away as programs get\nupdated and no longer works in translated mode.\n\nTry git in unix mode and, if you need it, use the core.autocrl setting to have git\ntranslate explicitly. There are plenty editors that honour line endings in Windows\nso LF mode works out quite well nowadays (for me, on my machines).\n\n-- robin\n"}]}