Git, Nuget, and line endings. Why does it have to be so hard?

Question

I am using git, nuget, and Visual Studio 2015 on a Windows machine.

I have a project that I have made that gets built into a content-only nuget package. The content of the package is two files:

File1.ttinclude
File2.ttinclude

These files MUST have CRLF line endings. I thought this was the default for Windows. I've tried all sorts of git settings and have settled on the following in my global git settings:

autocrlf = false

I can push the files to a remote repo and clone the remote remote and the files appear to still have CRLF line endings.

My issue is when I try to include that nuget package into another project. Whenever I run install-package (or do it from the package manager) the files get added to the project with LF line endings and all hell breaks loose.

I've tried autocrl=true, I've tried adding *.ttinclude text eol=crlf to .gitattributes for the nuget package and the project that needs to include the package. Nothing seems to work and I'm at a loss.

How can I get nuget to install the content-only package and keep the correct line endings?

I've created the following git alias that I currently use when adding that nuget package to a project. It fixes the line ending issue until that nuget package is updated.

alias.fixeol=!git add . -u && git commit -m "start eol fix" && git rm --cache -r . && git reset --hard && git add . && git commit -m "end eol fix"

UPDATE 1: I just thought of this, because it also may be the issue. We use TeamCity as our build server and that's what's building the nuget package from my source. I didn't set it up though so I'm not 100% how it's setup. Does git on the build server also need to be setup a certain way? What about TeamCity settings?

UPDATE 2: So I just inspected the nuget package contents of the .nupkg and the line endings are LF, so it must be the build server. Now I just need to figure out what git needs to be set to on the build server and will changing it screw up other projects?

UPDATE 3 - SOLVED: It was a TeamCity issue. https://confluence.jetbrains.com/pages/viewpage.action?pageId=48105844

Setting 'Convert line-endings to CRLF' option to true fixed the issue. Of course, I'm not sure why it was an issue to begin with. I have autocrlf=false locally. The files are CRLF. If not setting that feature is equivalent to TC having autocrlf=false then shouldn't it have just worked? Currently I've only set that option to true on this particular project since it's just a content-only package which requires CRLF. I'm not sure how it would affect other projects.

Answer 1

I've tried adding *.ttinclude text eol=crlf to .gitattributes for the nuget package

That is the right solution: always set core.autocrlf to false, and rely on eol directives. Although see "Why isn’t eol=crlf honored in .gitattributes?":

I’d misunderstood what git actually does when marking a file with the text attribute. It always stores the files with LF line endings internally and only converts to CRLF on checkout

So another approach, if you don't need to compare version and if those .ttinclude files don't change much or ever, is to:

• use *.ttinclude -text
• save and commit them with CRLF.

Note that with TeamCity (which is using JGit), .gitattributes were not supported (until recently?):

• issue TW-16530
• Bug 301775
• issue TW-44834