{"thread":{"id":"8200","subject":"autocrlf","startedAt":"2007-05-18T10:11:52Z","lastAt":"2007-05-18T12:32:54Z","messageCount":5,"participants":["Andy Parkins","Raimund Bauer","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42462","messageId":"200705181111.53823.andyparkins@gmail.com","threadId":"8200","inReplyTo":null,"subject":"autocrlf","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T10:11:52Z","receivedAt":"2007-05-18T10:11:52Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI've just been playing with gitattributes and was trying the crlf attribute.  \nThe behaviour of this and/or core.autocrlf is not as I was expecting.\n\nWhat I had imagined was that I could use .gitattributes to tell git which \nfiles in my tree were text.  Then the line endings on checkout would be set \nas appropriate to my platform, and on check in set to LF.\n\nWhat actually happens is that any file with the crlf attribute is being \nchecked out with LF expanded to CRLF (I'm running Linux of course), which is \ncompletely not what I wanted.\n\nI've looked at convert.c:crlf_to_worktree(), and it seems that that is exactly \nwhat is programmed:\n\n    dst = buffer;\n    do {\n        unsigned char c = *src++;\n        if (c == '\\n' && last != '\\r')\n            *dst++ = '\\r';\n        *dst++ = c;\n        last = c;\n    } while (--size);\n\nThis seems completely crazy.  What is automatic about that?  I had imagined \nthe point of the crlf flag was to make it possible for windows users and \nlinux users to work on the same project, each using their native line endings \nlocally.  Have I misunderstood?  Am I doing something wrong?\n\nHow would you set up a repository so that checking it out on Linux results in \nLF endings, and on Windows it results in CRLF endings?\n\nThis also makes me think that the crlf attribute is wrong; what I really want \nto say in .gitattributes is something like\n\n# Check out text to platform-dependent endings\n*.txt lineending=native\n# Check out svg to LF endings\n*.svg lineending=lf\n# Check out Z80 assembly files to CRLF\n*.mac lineending=crlf\n# Check out png untouched\n*.png lineending=binary\n\nWith the default for the lineending attribute being \"binary\".\n\nThen in .git/config I would have \"core.nativelineending = crlf\"; with the \ndefault being to use the ending appropriate to the platform.\n\nI'll write patches for this, but I wanted to make sure I haven't completely \ngotten the wrong end of the stick before I do.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42465","messageId":"1179484482.6453.19.camel@localhost","threadId":"8200","inReplyTo":"200705181111.53823.andyparkins@gmail.com","subject":"Re: autocrlf","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2007-05-18T10:34:42Z","receivedAt":"2007-05-18T10:34:42Z","isPatch":false,"sender":{"key":"ray007@gmx.net","avatar":null},"body":"On Fri, 2007-05-18 at 11:11 +0100, Andy Parkins wrote:\n> Hello,\n> \n> I've just been playing with gitattributes and was trying the crlf attribute.  \n> The behaviour of this and/or core.autocrlf is not as I was expecting.\n> \n> What I had imagined was that I could use .gitattributes to tell git which \n> files in my tree were text.  Then the line endings on checkout would be set \n> as appropriate to my platform, and on check in set to LF.\n> \n> What actually happens is that any file with the crlf attribute is being \n> checked out with LF expanded to CRLF (I'm running Linux of course), which is \n> completely not what I wanted.\n\nyou need to set core.autoCrlf=input\n\nI had the same problem some time ago ...\n\n> Andy\n\n-- \nbest regards\n\n  Ray\n"},{"id":"42470","messageId":"464D91E7.FB3F9B4@eudaptics.com","threadId":"8200","inReplyTo":"200705181111.53823.andyparkins@gmail.com","subject":"Re: autocrlf","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-18T11:45:43Z","receivedAt":"2007-05-18T11:45:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Andy Parkins wrote:\n> What I had imagined was that I could use .gitattributes to tell git which\n> files in my tree were text.  Then the line endings on checkout would be set\n> as appropriate to my platform, and on check in set to LF.\n> \n> What actually happens is that any file with the crlf attribute is being\n> checked out with LF expanded to CRLF (I'm running Linux of course), which is\n> completely not what I wanted.\n\nIf I understand the documentation correctly\n(Documentation/gitattributes.txt) then you set core.autocrlf to true on\nWindows and false everywhere else, and things should start working like\nyou imagined.\n\nI have not checked whether the behavior is according to the\ndocumentation, though.\n\n-- Hannes\n"},{"id":"42472","messageId":"200705181301.25749.andyparkins@gmail.com","threadId":"8200","inReplyTo":"1179484482.6453.19.camel@localhost","subject":"Re: autocrlf","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T12:01:18Z","receivedAt":"2007-05-18T12:01:18Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Raimund Bauer wrote:\n\n> you need to set core.autoCrlf=input\n>\n> I had the same problem some time ago ...\n\nThe documentation says:\n\ncore.autocrlf::\n    If true, makes git convert `CRLF` at the end of lines in text files to\n    `LF` when reading from the filesystem, and convert in reverse when\n    writing to the filesystem.  The variable can be set to\n    'input', in which case the conversion happens only while\n    reading from the filesystem but files are written out with\n    `LF` at the end of lines.  Currently, which paths to consider\n    \"text\" (i.e. be subjected to the autocrlf mechanism) is\n    decided purely based on the contents.\n\nThat is: \"input\" ensures that CRLF is stripped on input to the repository.  \nWhile that is fine in some circumstances, the situation I'm describing here \nis what happens on output from the repository.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"42475","messageId":"200705181332.55228.andyparkins@gmail.com","threadId":"8200","inReplyTo":"464D91E7.FB3F9B4@eudaptics.com","subject":"Re: autocrlf","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-18T12:32:54Z","receivedAt":"2007-05-18T12:32:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 May 18, Johannes Sixt wrote:\n\n> > What actually happens is that any file with the crlf attribute is being\n> > checked out with LF expanded to CRLF (I'm running Linux of course), which\n> > is completely not what I wanted.\n>\n> If I understand the documentation correctly\n> (Documentation/gitattributes.txt) then you set core.autocrlf to true on\n> Windows and false everywhere else, and things should start working like\n> you imagined.\n\nPresumably then it is defaulting to false for Linux as everything is working \nfine for me at present.  However, that is not the case when I set the crlf \nattribute.\n\nDocumentation/gitattributes.txt:\n\nThis attribute controls the line-ending convention.\n\nSet::\n\n    Setting the `crlf` attribute on a path is meant to mark\n    the path as a \"text\" file.  'core.autocrlf' conversion\n    takes place without guessing the content type by\n    inspection.\n\nI read that as meaning the automatic detection of file type is overridden by \nthe crlf attribute.  What I'm actually seeing is that it has the same effect \nas enabling \"autocrlf = true\" for that file.  As you say \"autocrlf = true\" is \nfor windows, the crlf attribute should not be forcing it on as that then \napplies to all platforms.\n\nI think this is a bug.  The code agrees with the observed behaviour but not \nwith the documentation.  Patch to follow.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"}]}