{"thread":{"id":"26294","subject":"EOL strangeness","startedAt":"2011-01-17T19:56:35Z","lastAt":"2011-01-20T16:29:27Z","messageCount":3,"participants":["Graham Sanderson","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159560","messageId":"AANLkTiknxMh_OophKWsqkYO2C+PsfF0ZnNXKLbheM4wF@mail.gmail.com","threadId":"26294","inReplyTo":null,"subject":"EOL strangeness","fromName":"Graham Sanderson","fromEmail":"graham.sanderson@gmail.com","sentAt":"2011-01-17T19:56:35Z","receivedAt":"2011-01-17T19:56:35Z","isPatch":false,"sender":{"key":"graham.sanderson@gmail.com","avatar":null},"body":"Apologies if someone has answered this before:\n\nSo we have moved some big teams over to git (awesome thx), and have\nbeen using the msysgit default core.autocrlf=true on Windows, and\nmaking sure text files are LF on other platforms\n\nHowever we do continue to have a few problems with people storing CRLF\nin the repository (partly because of lack of understanding, and partly\nit seems because of eGit on windows which ignores core.autocrlf).\n\nAnyway, this much is all fine, and we can fix; what I don't understand\nis why for files stored as CRLF in the repository it seems\nindeterminate when or if they show up locally modified (on my window\nbox with core.autocrlf = true) when I pull them from the repository. I\nassume the idea is that that they \"would be\" modified if I were to\ncheck them in, since they would be converted to LF, however this only\nhappens sometimes and for a seemingly random subset of the files\nstored incorrectly.\n\nIt also seems to depend on the state of the local index, as recreating\nthe local index often changes the set of files that are displayed this\nway (even without any changes to the files), and it also seems to be\ndifferent on different machines (perhaps based on when they happened\nto pull code).\n\nIf anyone can give me a quick mental picture of how this is supposed\nto work (i.e. at what time the eol conversions are considered) then\nthat'd be great... otherwise I guess I'll go dig in the code.\n\nThanks,\n\nGraham.\n"},{"id":"159685","messageId":"4D37F853.1020805@lsrfire.ath.cx","threadId":"26294","inReplyTo":"AANLkTiknxMh_OophKWsqkYO2C+PsfF0ZnNXKLbheM4wF@mail.gmail.com","subject":"Re: EOL strangeness","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-01-20T08:54:43Z","receivedAt":"2011-01-20T08:54:43Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 17.01.2011 20:56, schrieb Graham Sanderson:\n> Apologies if someone has answered this before:\n> \n> So we have moved some big teams over to git (awesome thx), and have\n> been using the msysgit default core.autocrlf=true on Windows, and\n> making sure text files are LF on other platforms\n> \n> However we do continue to have a few problems with people storing CRLF\n> in the repository (partly because of lack of understanding, and partly\n> it seems because of eGit on windows which ignores core.autocrlf).\n> \n> Anyway, this much is all fine, and we can fix; what I don't understand\n> is why for files stored as CRLF in the repository it seems\n> indeterminate when or if they show up locally modified (on my window\n> box with core.autocrlf = true) when I pull them from the repository. I\n> assume the idea is that that they \"would be\" modified if I were to\n> check them in, since they would be converted to LF, however this only\n> happens sometimes and for a seemingly random subset of the files\n> stored incorrectly.\n> \n> It also seems to depend on the state of the local index, as recreating\n> the local index often changes the set of files that are displayed this\n> way (even without any changes to the files), and it also seems to be\n> different on different machines (perhaps based on when they happened\n> to pull code).\n> \n> If anyone can give me a quick mental picture of how this is supposed\n> to work (i.e. at what time the eol conversions are considered) then\n> that'd be great... otherwise I guess I'll go dig in the code.\n\nPerhaps this recent thread is of interest to you, even though it's on a\nslightly different topic and inconclusive:\n\n\thttp://thread.gmane.org/gmane.comp.version-control.git/163794\n\nIt would be nice to have the expectations in your case codified in a\ntest script -- based on the documentation, if possible.\n\nRené\n"},{"id":"159696","messageId":"AANLkTimLFT48HCeFcqO_gn0XeBYkH=n8e124Y5RznLuC@mail.gmail.com","threadId":"26294","inReplyTo":"4D37F853.1020805@lsrfire.ath.cx","subject":"Re: EOL strangeness","fromName":"Graham Sanderson","fromEmail":"graham.sanderson@gmail.com","sentAt":"2011-01-20T16:29:27Z","receivedAt":"2011-01-20T16:29:27Z","isPatch":false,"sender":{"key":"graham.sanderson@gmail.com","avatar":null},"body":"Thanks, I think it must have been a bug - I realized that even though\nI thought I was on the latest git, I had an older copy hiding in my\npath; once I upgraded the problem went away.\n\nOn Thu, Jan 20, 2011 at 2:54 AM, René Scharfe\n<rene.scharfe@lsrfire.ath.cx> wrote:\n> Am 17.01.2011 20:56, schrieb Graham Sanderson:\n>> Apologies if someone has answered this before:\n>>\n>> So we have moved some big teams over to git (awesome thx), and have\n>> been using the msysgit default core.autocrlf=true on Windows, and\n>> making sure text files are LF on other platforms\n>>\n>> However we do continue to have a few problems with people storing CRLF\n>> in the repository (partly because of lack of understanding, and partly\n>> it seems because of eGit on windows which ignores core.autocrlf).\n>>\n>> Anyway, this much is all fine, and we can fix; what I don't understand\n>> is why for files stored as CRLF in the repository it seems\n>> indeterminate when or if they show up locally modified (on my window\n>> box with core.autocrlf = true) when I pull them from the repository. I\n>> assume the idea is that that they \"would be\" modified if I were to\n>> check them in, since they would be converted to LF, however this only\n>> happens sometimes and for a seemingly random subset of the files\n>> stored incorrectly.\n>>\n>> It also seems to depend on the state of the local index, as recreating\n>> the local index often changes the set of files that are displayed this\n>> way (even without any changes to the files), and it also seems to be\n>> different on different machines (perhaps based on when they happened\n>> to pull code).\n>>\n>> If anyone can give me a quick mental picture of how this is supposed\n>> to work (i.e. at what time the eol conversions are considered) then\n>> that'd be great... otherwise I guess I'll go dig in the code.\n>\n> Perhaps this recent thread is of interest to you, even though it's on a\n> slightly different topic and inconclusive:\n>\n>        http://thread.gmane.org/gmane.comp.version-control.git/163794\n>\n> It would be nice to have the expectations in your case codified in a\n> test script -- based on the documentation, if possible.\n>\n> René\n>\n"}]}