Git, Nuget y finales de línea. ¿Por qué tiene que ser tan difícil?

Estoy usando git, nuget y Visual Studio 2015 en una máquina con Windows.

Tengo un proyecto que he hecho que se integra en un package nuget de contenido único. El contenido del package es dos files:

 File1.ttinclude
 File2.ttinclude

Estos files DEBEN tener terminaciones de línea CRLF. Pensé que este era el valor pnetworkingeterminado para Windows. He intentado todo tipo de configuraciones de git y me he conformado con lo siguiente en mi configuration global de git:

autocrlf = false 

Puedo enviar los files a un repository remoto y clonar el control remoto remoto y los files parecen tener terminaciones de línea CRLF.

Mi problema es cuando trato de include ese package nuget en otro proyecto. Cada vez que ejecuto install-package (o lo hago desde el administrador de packages), los files se agregan al proyecto con terminaciones de línea LF y se desata todo el infierno.

Intenté autocrl=true , intenté agregar *.ttinclude text eol=crlf a .gitattributes para el package nuget y el proyecto que debe include el package. Nada parece funcionar y estoy perdido.

¿Cómo puedo get Nuget para instalar el package de solo contenido y mantener las terminaciones de línea correctas?

Creé el siguiente alias git que uso actualmente al agregar ese package nuget a un proyecto. Corrige el problema de final de línea hasta que ese package nuget se actualice.

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"

ACTUALIZACIÓN 1: Solo pensé en esto, porque también puede ser el problema. Usamos TeamCity como nuestro server de compilation y eso es lo que está construyendo el package nuget de mi fuente. No lo configuré, así que no estoy al 100% de cómo está configurado. ¿Git en el server de compilation también debe configurarse de cierta manera? ¿Qué hay de la configuration de TeamCity?

ACTUALIZACIÓN 2: Así que acabo de inspeccionar los contenidos del package nuget de .nupkg y los finales de línea son LF, por lo que debe ser el server de compilation. Ahora solo tengo que averiguar en qué git se debe configurar en el server de compilation y ¿se cambiará si se estropean otros proyectos?

ACTUALIZACIÓN 3 – SOLUCIONADO: Fue un problema de TeamCity. https://confluence.jetbrains.com/pages/viewpage.action?pageId=48105844

Establecer la opción 'Convertir finales de línea a CRLF' en verdadero solucionó el problema. Por supuesto, no estoy seguro de por qué fue un problema para empezar. Tengo autocrlf = falso localmente. Los files son CRLF. Si no configurar esa característica es equivalente a TC con autocrlf = falso, entonces ¿no debería haber funcionado? Actualmente, solo establecí esa opción en true en este proyecto en particular, ya que solo se trata de un package de solo contenido que requiere CRLF. No estoy seguro de cómo afectaría a otros proyectos.

He intentado agregar *.ttinclude text eol=crlf a .gitattributes para el package nuget

Esa es la solución correcta: siempre establezca core.autocrlf en false y confíe en las directivas eol. Aunque vea " ¿Por qué no se eol=crlf en .gitattributes ? ":

No entendí lo que git realmente hace al marcar un file con el atributo de text . Siempre almacena los files con terminaciones de líneas LF internamente y solo convierte a CRLF en el process de pago.

Entonces, otro enfoque, si no necesita comparar la versión y si esos files .ttinclude no cambian mucho o nunca, es:

  • use *.ttinclude -text
  • guárdalos y compromételos con CRLF.

Tenga en count que con TeamCity (que está usando JGit), .gitattributes no fueron compatibles (¿hasta hace poco?):

  • cuestión TW-16530
  • Error 301775
  • cuestión TW-44834