EOL strangeness

EOL strangeness

[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.

Thanks,

Graham.

Re: EOL strangeness

[René Scharfe]

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é

Re: EOL strangeness

[Graham Sanderson]

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:
> 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é
>