45

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?

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
Scott Davies
  • 1,329
  • 3
  • 15
  • 16

2 Answers2

133

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
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you! I am going ahead with Unix line termination. – Scott Davies Aug 09 '09 at 00:02
  • 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) – RJFalconer Dec 28 '09 at 11:47
  • @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. – VonC Dec 28 '09 at 12:22
  • 3
    Note for self: one tricky side-effect of `autocrlf` at true: http://stackoverflow.com/questions/2016404/git-status-shows-modifications-git-checkout-file-doesnt-remove-them – VonC Jan 06 '10 at 22:48
  • 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. – donquixote Sep 20 '14 at 18:14
  • @donquixote I agree. I prefer dealing with eol changes using `core.eol` (I mentioned in http://stackoverflow.com/a/3209806/6309), as I dislike the kind of global setting for "all" files. – VonC Sep 20 '14 at 20:08
  • 1
    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 :) – Ciro Santilli OurBigBook.com Jan 23 '15 at 11:15
  • 1
    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. – Ed Randall Sep 30 '16 at 13:30
  • 2
    @EdRandall the closest would be: http://stackoverflow.com/a/34013278/6309, 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. – VonC Sep 30 '16 at 13:38
  • 1
    @VonC 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. – Ed Randall Oct 10 '16 at 11:33
  • 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" – Andrew Savinykh May 29 '18 at 02:17
3

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.

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
  • 41
    Hopefully Notepad compatibility isn't an important requirement. – Craig McQueen Aug 08 '09 at 23:55
  • No, Notepad compatibility is not an issue. Sounds like Unix termination is the better choice. Thank you! – Scott Davies Aug 09 '09 at 00:00
  • 10
    So does every program anyone ever uses on any computer ever. Except Notepad. – Bennett McElwee May 27 '13 at 22:36
  • 3
    @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](http://serverfault.com/a/808942/343888) or a bash/perl/python... script ending with CRLF and see. Even with vi(m) you'll see a lot of `^M`s when opening a Windows text file – phuclv Nov 16 '16 at 09:54
  • 1
    At least in modern `vim`s, you normally see `^M`s 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. – Soren Bjornstad Oct 22 '19 at 12:51
  • 2
    The latest version of Notepad handles this as of today. – Expenzor Jun 08 '20 at 06:58