Git 1.6.4 beta on Windows (msysgit) - Unix or DOS line termination

Question

I am installing msysgit 1.6.4 beta on my Windows Vista development VPC. An install screen is requesting whether I want to use Unix line termination or DOS line termination. Ordinarily, I'd choose DOS, but the setup text indicates that DOS termination may mean files do not work with all of Git's command line tools. The Unix line termination states "...most [Windows] applications can handle this...".

Does anyone know which option I should choose to use Git via the shell for my VS 2008 work?

Tripinnate

Answer 1

That settings during the install process of msysgit is actually here to fix the value of the core.autocrlf config.

core.autocrlf

If true, makes git convert CRLF at the end of lines in text files to LF when reading from the filesystem, and convert in reverse when writing to the filesystem.

The variable can be set to 'input', in which case the conversion happens only while reading from the filesystem but files are written out with LF at the end of lines.

Currently, which paths to consider "text" (i.e. be subjected to the autocrlf mechanism) is decided purely based on the contents.

I would insist on not trying to convert anything automagically, the side-effects are just too important (in term of potential merging conflict, especially on distributed development with different environments)

If your tools can handle Unix-style line termination, you should set them to produce Unix lines, which can then be read by Windows (VS2008, Notepad++, ...) and Unix alike, and can be processed by any 'sh' Git-scripts.

But with core.autocrlf set to false, the decision to transform a text line termination will be a voluntary explicit one, not a background invisible side-effect one.

---

See more at "How line ending conversions work with git core.autocrlf between different operating systems"

                 | Resulting conversion when       | Resulting conversion when 
                 | committing files with various   | checking out FROM repo - 
                 | EOLs INTO repo and              | with mixed files in it and
                 |  core.autocrlf value:           | core.autocrlf value:           
--------------------------------------------------------------------------------
File             | true       | input      | false | true       | input | false
--------------------------------------------------------------------------------
Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is

Bromide

Thank you! I am going ahead with Unix line termination. – Tripinnate

I don't see how you can get a merge conflict based on line endings. In the case where you have autocrlf True, if you fetch from someone who has CRLF locally wouldn't the endings would be converted to LF (before the merge)? (You would also have any CRLF converted to LF if you have just pushed locally) – Conventual

@BlueNovember: the reasoning is that you can not guarantee every Git in every environment has that setting properly set. Even if you do not get conflict in your environment, you may cause unsuspected problem in other remote Git clients. – Bromide

Note for self: one tricky side-effect of autocrlf at true: #2016904 – Bromide

The best would be a 3rd setting autocrlf=user, where git would warn about windows line endings being added or committed. then you'd have to add an option git commit --autocrlf=true or git commit --autocrlf=false to commit any windows style content. – Sorry

@Sorry I agree. I prefer dealing with eol changes using core.eol (I mentioned in https://mcmap.net/q/11292/-how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operating-systems), as I dislike the kind of global setting for "all" files. – Bromide

I don't like upvoting you because you because your rep is so insane already, but I've searched so much for that table that I must :) – Oneway

We are in a heterogeneous environment with mixture of file types. We absolutely want core.autocrlf=false. What I am unable to find anywhere, is how to set it false for the project so I don't have to rely on every developer getting their own setting right. – Hayashi

@EdRandall the closest would be: https://mcmap.net/q/11262/-any-way-to-put-my-hook-to-github-repo, but it would still require a manual git config to activate the smudge. The short answer is: any project local config has to be activated by the user. It is not automagically set by the project/repo itself. – Bromide

@Bromide what I did in the end was to add a check to the (ant-based) build which fails if if the user does not have it set false. The developers then learned pretty quickly to set it right. – Hayashi

This answer is very old so may be something changed since then. On windows I have core.autocrlf false, yet, I'm getting warning: LF will be replaced by CRLF warning when adding files with LF endings. This indicates that core.autocrlf false is NOT always "as-is" – Lamppost

Answer 2

Visual Studio 2008 handles Unix line terminations without problems. However, it will try to detect text files with inconsistent line terminations in an attempt to fix these. Notepad on the other hand is not able to properly display Unix text files.

Rectocele

Hopefully Notepad compatibility isn't an important requirement. – Gauntlett

No, Notepad compatibility is not an issue. Sounds like Unix termination is the better choice. Thank you! – Tripinnate

So does every program anyone ever uses on any computer ever. Except Notepad. – Trisomic

@BennettMcElwee every GUI program on every platform I know (including wordpad) except Notepad supports both CRLF and LF without problem. However the majority of console programs still doesn't deal with that. Try running a batch file ending with LF or a bash/perl/python... script ending with CRLF and see. Even with vi(m) you'll see a lot of ^Ms when opening a Windows text file – Misconceive

At least in modern vims, you normally see ^Ms only when the file has mixed line endings, so you can see which lines have CRLFs and which don't. If every line has the same line ending, it works fine in either Unix or DOS mode. – Decline

The latest version of Notepad handles this as of today. – Schematism