CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)

[Geert Janssens]

Op 23-02-13 11:35, Mike Evans schreef:
> On Sat, 23 Feb 2013 10:19:25 +0100
> Geert Janssens <janssens-geert at telenet.be> wrote:
>
>> Op 23-02-13 05:52, John Ralls schreef:
>>> On Feb 22, 2013, at 11:14 AM, Geert Janssens
>>> <janssens-geert at telenet.be> wrote:
>>>
>>>> Op 22-02-13 19:45, Geert Janssens schreef:
>>>>> Op 22-02-13 19:23, Mike Evans schreef:
>>>>>> Thanks for checking Geert.  I removed my $HOME/.gitconfig and
>>>>>> tried again with the same result.  My git version is 1.7.6.5 on
>>>>>> Fedora 15 not sure it that makes any difference.  Anyway now we
>>>>>> know where the problem is (me) I know the solution is local.
>>>>>> Enough for today though I think.
>>>>> My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't
>>>>> know if that makes a difference or not.
>>>>>
>>>>> What exact url are you using to clone from github ?
>>>>> Mine is git at github.com:Gnucash/gnucash.git
>>>>>
>>>>> Any other devs seeing this ?
>>>>>
>>>>> Geert
>>>> Additionally, can you check if the "eol" attribute is already
>>>> supported in your git version ? It is mentioned in "man
>>>> gitattributes" on my system and is the attribute I'm using to
>>>> force consistent line endings. It may be a more recent addition.
>>>>
>>> Yeah, I see it on OSX.  When I follow the "renormalizing"
>>> procedure, I get warning: CRLF will be replaced by LF in
>>> src/report/jqplot/foo.js. The file will have its original line
>>> endings in your working directory. For all of the files that Mike
>>> listed. Curiously, changing the *.js entry in .gitattributes to
>>> crlf and repeating the procedure has no effect. It appears that you
>>> got those js files into the repo with crlf line endings.
>>>
>>> git version 1.7.9.6 (Apple Git-31.1)
>>> The "eol" attribute is documented in gitattributes(5)
>>>
>>> Regards,
>>> John Ralls
>>>
>> Ok, that is very likely. Can you or Mike check in the proper
>> conversions ? They don't show up on my system (which I don't
>> understand why that is).
>>
>> Geert
> OK checked in as r22808 4317a28b55655
>
> Mike E
>
Thanks.

Git is still happy on my system with the new commit and after 
renormalizing. So hopefully we fixed it properly this time.

Geert