threads / discuss / 26294

EOL strangeness

Subject: EOL strangeness

## tl;dr

3 messages between Jan 17, 2011 and Jan 20, 2011.

replies: 2people: 2as markdown or json

Graham Sanderson· Jan 17, 2011, 19:56 UTC · lore

Apologies if someone has answered this before:

So we have moved some big teams over to git (awesome thx), and have been using the msysgit default core.autocrlf=true on Windows, and making sure text files are LF on other platforms

However we do continue to have a few problems with people storing CRLF in the repository (partly because of lack of understanding, and partly it seems because of eGit on windows which ignores core.autocrlf).

Anyway, this much is all fine, and we can fix; what I don't understand is why for files stored as CRLF in the repository it seems indeterminate when or if they show up locally modified (on my window box with core.autocrlf = true) when I pull them from the repository. I assume the idea is that that they "would be" modified if I were to check them in, since they would be converted to LF, however this only happens sometimes and for a seemingly random subset of the files stored incorrectly.

It also seems to depend on the state of the local index, as recreating the local index often changes the set of files that are displayed this way (even without any changes to the files), and it also seems to be different on different machines (perhaps based on when they happened to pull code).

If anyone can give me a quick mental picture of how this is supposed to work (i.e. at what time the eol conversions are considered) then that'd be great... otherwise I guess I'll go dig in the code.

Thanks,

Graham.

René Scharfe· Jan 20, 2011, 08:54 UTC · re: Graham Sanderson · lore

Re: EOL strangeness

Am 17.01.2011 20:56, schrieb Graham Sanderson:

Show 28 quoted lines

> Apologies if someone has answered this before:
> 
> So we have moved some big teams over to git (awesome thx), and have
> been using the msysgit default core.autocrlf=true on Windows, and
> making sure text files are LF on other platforms
> 
> However we do continue to have a few problems with people storing CRLF
> in the repository (partly because of lack of understanding, and partly
> it seems because of eGit on windows which ignores core.autocrlf).
> 
> Anyway, this much is all fine, and we can fix; what I don't understand
> is why for files stored as CRLF in the repository it seems
> indeterminate when or if they show up locally modified (on my window
> box with core.autocrlf = true) when I pull them from the repository. I
> assume the idea is that that they "would be" modified if I were to
> check them in, since they would be converted to LF, however this only
> happens sometimes and for a seemingly random subset of the files
> stored incorrectly.
> 
> It also seems to depend on the state of the local index, as recreating
> the local index often changes the set of files that are displayed this
> way (even without any changes to the files), and it also seems to be
> different on different machines (perhaps based on when they happened
> to pull code).
> 
> If anyone can give me a quick mental picture of how this is supposed
> to work (i.e. at what time the eol conversions are considered) then
> that'd be great... otherwise I guess I'll go dig in the code.

Perhaps this recent thread is of interest to you, even though it's on a slightly different topic and inconclusive:

	http://thread.gmane.org/gmane.comp.version-control.git/163794

It would be nice to have the expectations in your case codified in a test script -- based on the documentation, if possible.

René

Graham Sanderson· Jan 20, 2011, 16:29 UTC · re: René Scharfe · lore

Re: EOL strangeness

Thanks, I think it must have been a bug - I realized that even though I thought I was on the latest git, I had an older copy hiding in my path; once I upgraded the problem went away.

On Thu, Jan 20, 2011 at 2:54 AM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

Show 40 quoted lines

> Am 17.01.2011 20:56, schrieb Graham Sanderson:
>> Apologies if someone has answered this before:
>>
>> So we have moved some big teams over to git (awesome thx), and have
>> been using the msysgit default core.autocrlf=true on Windows, and
>> making sure text files are LF on other platforms
>>
>> However we do continue to have a few problems with people storing CRLF
>> in the repository (partly because of lack of understanding, and partly
>> it seems because of eGit on windows which ignores core.autocrlf).
>>
>> Anyway, this much is all fine, and we can fix; what I don't understand
>> is why for files stored as CRLF in the repository it seems
>> indeterminate when or if they show up locally modified (on my window
>> box with core.autocrlf = true) when I pull them from the repository. I
>> assume the idea is that that they "would be" modified if I were to
>> check them in, since they would be converted to LF, however this only
>> happens sometimes and for a seemingly random subset of the files
>> stored incorrectly.
>>
>> It also seems to depend on the state of the local index, as recreating
>> the local index often changes the set of files that are displayed this
>> way (even without any changes to the files), and it also seems to be
>> different on different machines (perhaps based on when they happened
>> to pull code).
>>
>> If anyone can give me a quick mental picture of how this is supposed
>> to work (i.e. at what time the eol conversions are considered) then
>> that'd be great... otherwise I guess I'll go dig in the code.
>
> Perhaps this recent thread is of interest to you, even though it's on a
> slightly different topic and inconclusive:
>
>        http://thread.gmane.org/gmane.comp.version-control.git/163794
>
> It would be nice to have the expectations in your case codified in a
> test script -- based on the documentation, if possible.
>
> René
>