Git line endings

[Mauricio Scheffer]

If anyone's having problems with git diffs showing ^M or other weird
line-ending-related things, you need to set the core.autocrlf setting,
then refresh your working copy. Here are the instructions:
http://help.github.com/dealing-with-lineendings/

You can check if your files have CRLF (and not just LF) with a proper
text editor like Notepad++

Cheers,
Mauricio

[Krzysztof Koźmic]

and which one should they have?

[Julian Birch]

CRLF

On Saturday, February 27, 2010, Krzysztof Koźmic

> --
> You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
>
>

[Daniel Hölbling]

I suggest disabling the core.autocrlf feature completely. It really screws up your commits if for some reason tools modify the line-endings.

Nothing is more annoying than having a commit where you get a deletion/insert for every line in the document although you only changed 2 LOC.. 

In fact, I got so annoyed about this that I even blogged about that:

http://www.tigraine.at/2010/02/03/disable-autcrlf-in-msysgit/

I still have no real explanation how inconsistent file endings started to occur on a Windows-only environment, but it happened a lot to me in the past, and I've seen too many commits being completely unreadable due to this.

greetings Daniel

[Roelof Blom]

+1, just leave the line endings as they are.

I have a feeling that inconsistent line endings could be caused by R#, at least the current EAP seems to have something to do with this. Note that you can set VSNET to warn you about inconsistent line endings: Tools|Options|Environment|Documents => Check for consistent line endings on load.

-- Roelof.

[Daniel Hölbling]

R# may have something to do with it. Hope they fix it. But as long as the build scripts and our tools can cope with different line endings in different files I don't feel like we should at all care about them in our repos. 

[Roelof Blom]

It's a problem with some of the unit tests.

[Mauricio Scheffer]

I do this on my git repositories at work and it works like a charm,
but it doesn't seem to be the case with Castle. With autocrlf false,
certain files are LF-only, like WindsorContainer.cs, while other files
are CRLF.
As I understand it, autocrlf true makes sure that everything is CRLF
on Windows.

Cheers,
Mauricio

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bun subs...@googlegroups.com>

[Craig Neuwirt]

Henry,

I was trying to work on WCF Facilities release over the weekend and noticed when I pulled from origin I had a bunch of files that always showed dirty files.  Setting git config core.autocrlf false had not affect either.   When I did a diff on the files it only show permission changes which led me to the conclusion that some recent commits have altered file permissions.  I tried to tell git to ignore this global with git config --global core.filemode false, but it didn't work.  However, setting this locally only did.   So git config core.filemode false got things rolling again.

-craig

[Daniel Hölbling]

I had the problem with autocrlf. Upon checkout of the tree it marked all files as dirty that had the wrong file endings. From what I understood msysgit will change the line endings upon checkout to be consistent with your setting. I'm still for just disabling autocrlf..