Re: [msysGit] Re: "CRLF will be replaced by LF" warning
2,071 views
Skip to first unread message
Carsten Fuchs
Apr 12, 2013, 12:43:33 PM4/12/13
to msy...@googlegroups.com
Am 2013-04-10 21:05, schrieb carste...@cafu.de:
> The problem described in my original message seems to stem from the fact that the line
> endings are not written as CRLF in the working directory.
>
> Please consider these simple steps to see the problem:
> [...]
Can someone help me?
Can someone reproduce this problem?
Best regards,
Carsten
> The problem described in my original message seems to stem from the fact that the line
> endings are not written as CRLF in the working directory.
>
> Please consider these simple steps to see the problem:
> [...]
Can someone help me?
Can someone reproduce this problem?
Best regards,
Carsten
Sebastian Schuberth
Apr 12, 2013, 4:45:31 PM4/12/13
to carste...@cafu.de, msy...@googlegroups.com
On 08.04.2013 10:07, carste...@cafu.de wrote:
> > d:\Dev\Cafu> git add Libs\GuiSys\CompBasics.cpp
> > warning: CRLF will be replaced by LF in Libs/GuiSys/CompBasics.cpp.
> > The file will have its original line endings in your working directory.
>
> Well... this seems to be entirely correct, but why do I see it?
> How can I get rid of this message?
That would be the core.safecrlf setting, which is set to "warn" by
default for Git for Windows, IIRC. Setting core.safecrlf to false should
get rid of the message.
--
Sebastian Schuberth
> > d:\Dev\Cafu> git add Libs\GuiSys\CompBasics.cpp
> > warning: CRLF will be replaced by LF in Libs/GuiSys/CompBasics.cpp.
> > The file will have its original line endings in your working directory.
>
> Well... this seems to be entirely correct, but why do I see it?
> How can I get rid of this message?
That would be the core.safecrlf setting, which is set to "warn" by
default for Git for Windows, IIRC. Setting core.safecrlf to false should
get rid of the message.
--
Sebastian Schuberth
Sebastian Schuberth
Apr 12, 2013, 4:55:25 PM4/12/13
to msy...@googlegroups.com, msy...@googlegroups.com
On 10.04.2013 21:05, carste...@cafu.de wrote:
> When you now look at any of the .h, .hpp, ... files declared as "text"
> in .gitattributes, they all have LF instead of the expacted CRLF line
> endings. (Note that core.eol is not set.)
>
> Why?
If core.eol is not set it defaults to "native", which uses the
platform's native line ending. But I suspect the platform is not Windows
in this case, but MSYS, so the native line ending is LF and not CRLF.
--
Sebastian Schuberth
> When you now look at any of the .h, .hpp, ... files declared as "text"
> in .gitattributes, they all have LF instead of the expacted CRLF line
> endings. (Note that core.eol is not set.)
>
> Why?
If core.eol is not set it defaults to "native", which uses the
platform's native line ending. But I suspect the platform is not Windows
in this case, but MSYS, so the native line ending is LF and not CRLF.
--
Sebastian Schuberth
Carsten Fuchs
Apr 12, 2013, 7:17:38 PM4/12/13
to Sebastian Schuberth, msy...@googlegroups.com
Hi Sebastian,
thank you very much for your reply! :-)
Am 2013-04-12 22:55, schrieb Sebastian Schuberth:
> If core.eol is not set it defaults to "native", which uses the platform's native line
> ending. But I suspect the platform is not Windows in this case, but MSYS, so the native
> line ending is LF and not CRLF.
Indeed, when I set core.eol to crlf, then it works in the sense that the checked out
files have CRLF line endings.
But... if the native line ending in MSYS on Windows is LF and not CRLF, then it's LF
everywhere, isn't it? Then, what's the purpose of "native", after all?
(Considering the enormous amount of Git documentation that exists about this topic
alone, including the Git man pages,
http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/, two printed and two
online books that I've read, honestly I start to feel a little stupid...)
Anyways, what can be done about it? Does every Windows user manually have to configure
core.eol to crlf?
I found the related SO post
http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
where a fix was mentioned, but not how it turned out?
Best regards,
Carsten
thank you very much for your reply! :-)
Am 2013-04-12 22:55, schrieb Sebastian Schuberth:
> If core.eol is not set it defaults to "native", which uses the platform's native line
> ending. But I suspect the platform is not Windows in this case, but MSYS, so the native
> line ending is LF and not CRLF.
files have CRLF line endings.
But... if the native line ending in MSYS on Windows is LF and not CRLF, then it's LF
everywhere, isn't it? Then, what's the purpose of "native", after all?
(Considering the enormous amount of Git documentation that exists about this topic
alone, including the Git man pages,
http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/, two printed and two
online books that I've read, honestly I start to feel a little stupid...)
Anyways, what can be done about it? Does every Windows user manually have to configure
core.eol to crlf?
I found the related SO post
http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
where a fix was mentioned, but not how it turned out?
Best regards,
Carsten
Carsten Fuchs
Apr 12, 2013, 7:23:37 PM4/12/13
to Sebastian Schuberth, msy...@googlegroups.com
Hi Sebastian,
Am 2013-04-12 22:45, schrieb Sebastian Schuberth:
> That would be the core.safecrlf setting, which is set to "warn" by default for Git for
> Windows, IIRC. Setting core.safecrlf to false should get rid of the message.
Having core.eol set to crlf as you suggested in the other post, the warning message does
no longer occur!
Again, many thanks for your help! :-)
Best regards,
Carsten
Am 2013-04-12 22:45, schrieb Sebastian Schuberth:
> That would be the core.safecrlf setting, which is set to "warn" by default for Git for
> Windows, IIRC. Setting core.safecrlf to false should get rid of the message.
no longer occur!
Again, many thanks for your help! :-)
Best regards,
Carsten
Sebastian Schuberth
Apr 13, 2013, 8:52:19 AM4/13/13
to Carsten Fuchs, msy...@googlegroups.com
On Sat, Apr 13, 2013 at 1:23 AM, Carsten Fuchs <carste...@cafu.de> wrote:
> Having core.eol set to crlf as you suggested in the other post, the warning
> message does no longer occur!
>
> Again, many thanks for your help! :-)
You're welcome. This way I could at least show my appreciation for
> Having core.eol set to crlf as you suggested in the other post, the warning
> message does no longer occur!
>
> Again, many thanks for your help! :-)
your 3D engine :-)
--
Sebastian Schuberth
Sebastian Schuberth
Apr 13, 2013, 9:03:13 AM4/13/13
to Carsten Fuchs, msy...@googlegroups.com
On Sat, Apr 13, 2013 at 1:17 AM, Carsten Fuchs <carste...@cafu.de> wrote:
> Indeed, when I set core.eol to crlf, then it works in the sense that the
> checked out files have CRLF line endings.
>
> But... if the native line ending in MSYS on Windows is LF and not CRLF, then
> it's LF everywhere, isn't it? Then, what's the purpose of "native", after
> all?
Well, of course "native" is supposed to be CRLF on Windows and any
> Indeed, when I set core.eol to crlf, then it works in the sense that the
> checked out files have CRLF line endings.
>
> But... if the native line ending in MSYS on Windows is LF and not CRLF, then
> it's LF everywhere, isn't it? Then, what's the purpose of "native", after
> all?
fully native Git for Windows client should adhere to that. By "fully
native" I mean a Git for Windows that does not rely on *any* Unix-like
tools. Although git.exe itself *is* a native Windows executable in the
sense that it does not depend on the MSYS emulation layer, several
tools that Git depends on are MSYS executables or shell scripts, and
in fact some Git commands themselves still are shell or Perl scripts.
As long as this is the case I guess there will be some confusion about
what "native" is and how line end conversion works. Maybe some day all
of the Git functionality will be available in libgit2, and someone
could come up with a Git client that just links against libgit2.
> Anyways, what can be done about it? Does every Windows user manually have to
> configure core.eol to crlf?
not simply use core.autocrlf=true, which is what the Git for Windows
installer suggests by default? For years I'm developing cross-platform
projects just fine with that setting on Windows (and either
core.autocrlf=false or =input on Linux).
> I found the related SO post
> http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
> where a fix was mentioned, but not how it turned out?
--
Sebastian Schuberth
Carsten Fuchs
Apr 14, 2013, 4:36:23 AM4/14/13
to Sebastian Schuberth, msy...@googlegroups.com
Hi Sebastian,
Am 2013-04-13 15:03, schrieb Sebastian Schuberth:
> [...] As long as this is the case I guess there will be some confusion about
> Why are you bothering with .gitattributes and core.eol after all and
> not simply use core.autocrlf=true, which is what the Git for Windows
> installer suggests by default?
Well... when I started with Git and was only learning it, things were already
overwhelming enough: a complicated repository conversion from Subversion, including
history rewriting, occupied me enough so that I did not want to dig through yet another
frustratingly complex topic. So I decided to defer this until later, and the only safe
way to do this seemed to be setting core.autocrlf=false even on Windows (I was
planning / intending for a single, controlled "renormalize line endings" commit, rather
than Git interfering with things when I was not prepared for them).
Then, my repository has many kinds of text files: not just C/C++ source, but also many
kinds of script, and even several data files have text format. Especially with all those
I wanted to initiate and review any eol normalization explicitly.
And finally, http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ clearly
labels core.autocrlf etc. as "The Old System", and .gitattributes as "The New
System" (which also seems much simpler to understand), so I wanted to get it "right"
from the start. ;)
>> I found the related SO post
>> http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
>> where a fix was mentioned, but not how it turned out?
>
> TL;DR, sorry ...
Same problem description, with proposal of a fix.
I searched some more, the above is referring to
http://thread.gmane.org/gmane.comp.version-control.msysgit/17193/focus=17194
But I wonder if this commit ever made it somewhere?
Best regards,
Carsten
Am 2013-04-13 15:03, schrieb Sebastian Schuberth:
> [...] As long as this is the case I guess there will be some confusion about
> what "native" is and how line end conversion works. Maybe some day all
> of the Git functionality will be available in libgit2, and someone
> could come up with a Git client that just links against libgit2.
Ok, thanks!
> of the Git functionality will be available in libgit2, and someone
> could come up with a Git client that just links against libgit2.
> Why are you bothering with .gitattributes and core.eol after all and
> not simply use core.autocrlf=true, which is what the Git for Windows
> installer suggests by default?
overwhelming enough: a complicated repository conversion from Subversion, including
history rewriting, occupied me enough so that I did not want to dig through yet another
frustratingly complex topic. So I decided to defer this until later, and the only safe
way to do this seemed to be setting core.autocrlf=false even on Windows (I was
planning / intending for a single, controlled "renormalize line endings" commit, rather
than Git interfering with things when I was not prepared for them).
Then, my repository has many kinds of text files: not just C/C++ source, but also many
kinds of script, and even several data files have text format. Especially with all those
I wanted to initiate and review any eol normalization explicitly.
And finally, http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ clearly
labels core.autocrlf etc. as "The Old System", and .gitattributes as "The New
System" (which also seems much simpler to understand), so I wanted to get it "right"
from the start. ;)
>> I found the related SO post
>> http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
>> where a fix was mentioned, but not how it turned out?
>
> TL;DR, sorry ...
I searched some more, the above is referring to
http://thread.gmane.org/gmane.comp.version-control.msysgit/17193/focus=17194
But I wonder if this commit ever made it somewhere?
Best regards,
Carsten
Carsten Fuchs
Apr 14, 2013, 4:38:34 AM4/14/13
to Sebastian Schuberth, msy...@googlegroups.com
Am 2013-04-13 14:52, schrieb Sebastian Schuberth:
> You're welcome. This way I could at least show my appreciation for
> your 3D engine :-)
Hehehe... thanks! :-)
> You're welcome. This way I could at least show my appreciation for
> your 3D engine :-)
Best regards,
Carsten
Sebastian Schuberth
Apr 14, 2013, 3:01:21 PM4/14/13
to Carsten Fuchs, Pat Thoyts, msy...@googlegroups.com, jrni...@gmail.com
On Sun, Apr 14, 2013 at 10:36 AM, Carsten Fuchs <carste...@cafu.de> wrote:
>> Why are you bothering with .gitattributes and core.eol after all and
>> not simply use core.autocrlf=true, which is what the Git for Windows
>> installer suggests by default?
>> Why are you bothering with .gitattributes and core.eol after all and
>> not simply use core.autocrlf=true, which is what the Git for Windows
>> installer suggests by default?
> And finally,
> http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ clearly
> labels core.autocrlf etc. as "The Old System", and .gitattributes as
> "The New System" (which also seems much simpler to understand), so I wanted
> to get it "right" from the start. ;)
Ah, I did not even know that core.autocrlf is sort of deprecated. I
> http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ clearly
> labels core.autocrlf etc. as "The Old System", and .gitattributes as
> "The New System" (which also seems much simpler to understand), so I wanted
> to get it "right" from the start. ;)
just worked so well for me that I never looked for anything else.
>>> I found the related SO post
>>>
>>> http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings,
>>> where a fix was mentioned, but not how it turned out?
> I searched some more, the above is referring to
> http://thread.gmane.org/gmane.comp.version-control.msysgit/17193/focus=17194
>
> But I wonder if this commit ever made it somewhere?
Interesting. Seems that Pat's commit is not on msysgit/git master yet,
> http://thread.gmane.org/gmane.comp.version-control.msysgit/17193/focus=17194
>
> But I wonder if this commit ever made it somewhere?
but only on pt/native-crlf.
@Pat, the commits of Jonathan and you seem to be important bug fixes
to me. Any reason why they are not merged yet?
--
Sebastian Schuberth
Carsten Fuchs
Apr 15, 2013, 5:07:34 PM4/15/13
to Sebastian Schuberth, Pat Thoyts, msy...@googlegroups.com, jrni...@gmail.com
comments on the Git list as well:
http://thread.gmane.org/gmane.comp.version-control.git/148436/focus=210370
Best regards,
Carsten
Sebastian Schuberth
Apr 16, 2013, 5:07:09 PM4/16/13
to Carsten Fuchs, Pat Thoyts, msy...@googlegroups.com, jrni...@gmail.com
On Mon, Apr 15, 2013 at 11:07 PM, Carsten Fuchs <carste...@cafu.de> wrote:
> Just for completeness and future reference, there is a related thread with
> recent comments on the Git list as well:
>
> http://thread.gmane.org/gmane.comp.version-control.git/148436/focus=210370
A fix has just been applied upstream, see my comment at
> Just for completeness and future reference, there is a related thread with
> recent comments on the Git list as well:
>
> http://thread.gmane.org/gmane.comp.version-control.git/148436/focus=210370
https://github.com/msysgit/git/issues/57.
--
Sebastian Schuberth
Reply all
Reply to author
Forward
0 new messages