tags:

views:

1001

answers:

2

I am installing msysgit 1.6.4 beta on my Win 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 ?

Thanks!

+2  A: 

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 hand is not able to properly display Unix text files.

Martin Liversage
Hopefully Notepad compatibility isn't an important requirement.
Craig McQueen
No, Notepad compatibility is not an issue. Sounds like Unix termination is the better choice. Thank you!
Scott Davies
Notepad++ works flawless with both line termination styles.
alexandrul
+8  A: 

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.

VonC
Thank you! I am going ahead with Unix line termination.
Scott Davies
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
@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
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