Intenté confirmar archivos con líneas que terminaban en CRLF, pero falló.

Pasé todo un día de trabajo en mi computadora con Windows probando diferentes estrategias y casi me atrajo dejar de intentar usar Git y, en cambio, probar Mercurial .

Comparta solo una práctica recomendada por respuesta.

¡Casi cuatro años después de hacer esta pregunta, finalmente encontré una respuesta que me satisface por completo !

Vea los detalles en github: guía de ayuda para tratar con terminaciones de línea .

Git le permite establecer las propiedades de final de línea para un repositorio directamente usando el atributo de texto en el .gitattributesarchivo. Este archivo se confirma en el repositorio y anula la core.autocrlfconfiguración, lo que le permite garantizar un comportamiento coherente para todos los usuarios, independientemente de su configuración de git.

Y por lo tanto

La ventaja de esto es que su configuración de final de línea ahora viaja con su repositorio y no necesita preocuparse por si los colaboradores tienen o no la configuración global adecuada.

Aquí hay un ejemplo de un .gitattributesarchivo

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Hay una colección conveniente de archivos .gitattributes listos para usar para los lenguajes de programación más populares. Es útil para comenzar.

Una vez que haya creado o ajustado su .gitattributes, debe realizar una re-normalización de terminaciones de línea de una vez por todas .

Tenga en cuenta que la aplicación de escritorio GitHub puede sugerir y crear un .gitattributesarchivo después de abrir el repositorio Git de su proyecto en la aplicación. Para intentarlo, haga clic en el ícono de ajustes (en la esquina superior derecha)> Configuración del repositorio ...> Terminaciones de línea y atributos. Se le pedirá que agregue lo recomendado .gitattributesy, si está de acuerdo, la aplicación también realizará una normalización de todos los archivos en su repositorio.

Finalmente, el artículo Mind the End of Your Line proporciona más antecedentes y explica cómo Git ha evolucionado en los asuntos en cuestión. Considero que esto requiere lectura .

Probablemente haya usuarios en su equipo que usen EGit o JGit (herramientas como Eclipse y TeamCity los usan) para confirmar sus cambios. Entonces no tienes suerte, como @gatinueta explicó en los comentarios de esta respuesta:

Esta configuración no lo satisfará por completo si tiene personas que trabajan con Egit o JGit en su equipo, ya que esas herramientas simplemente ignorarán los atributos .gitattributes y contestarán felizmente los archivos CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

Un truco podría ser hacer que confirmen sus cambios en otro cliente, dice SourceTree . Nuestro equipo en aquel entonces prefirió esa herramienta al EGit de Eclipse para muchos casos de uso.

¿Quién dijo que el software es fácil? : - /

No convierta terminaciones de línea. No es trabajo del VCS interpretar datos, solo almacenarlos y versionarlos. Todos los editores de texto modernos pueden leer ambos tipos de terminaciones de línea de todos modos.

Casi siempre quieres a autocrlf=inputmenos que realmente sepas lo que estás haciendo.

Algún contexto adicional a continuación:

Debería ser core.autocrlf=truesi le gusta la terminación de DOS o core.autocrlf=inputsi prefiere unix-newlines. En ambos casos, su repositorio Git tendrá solo LF, que es lo correcto. El único argumento a favor core.autocrlf=falsees que la heurística automática puede detectar incorrectamente algunos archivos binarios como texto y luego su mosaico se dañará. Entonces, core.safecrlfse introdujo la opción para advertir a un usuario si ocurre un cambio irreversible. De hecho, hay dos posibilidades de cambios irreversibles: terminación de línea mixta en el archivo de texto, en esta normalización es deseable, por lo que esta advertencia puede ignorarse o (muy poco probable) que Git detecte incorrectamente su archivo binario como texto. Luego debe usar atributos para decirle a Git que este archivo es binario.

El párrafo anterior se extrajo originalmente de un hilo en gmane.org, pero desde entonces ha caído.

Dos estrategias alternativas para ser coherente con los finales de línea en entornos mixtos (Microsoft + Linux + Mac):

A. Configuración global para todos los repositorios

1) Convertir todo a un formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Establecer core.autocrlf de inputLinux / UNIX o trueen MS Windows (repositorio o global)

git config --global core.autocrlf input

3) [Opcional] establecido core.safecrlfentrue (para detener) o warn(para cantar :) para agregar protección adicional al comparar si la transformación de nueva línea invertida daría como resultado el mismo archivo

git config --global core.safecrlf true

B. O según la configuración del repositorio

1) Convertir todo a un formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) agregar .gitattributes archivo a tu repositorio

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

No se preocupe por sus archivos binarios: Git debería ser lo suficientemente inteligente al respecto.

Más información sobre las variables safecrlf / autocrlf

Intente establecer la core.autocrlfopción de configuración en true. También eche un vistazo a lacore.safecrlf opción.

En realidad, parece core.safecrlfque ya podría estar configurado en su repositorio, porque (el énfasis es mío):

Si este no es el caso para la configuración actual de core.autocrlf, git rechazará el archivo .

Si este es el caso, es posible que desee verificar que su editor de texto esté configurado para usar terminaciones de línea consistentemente. Es probable que tenga problemas si un archivo de texto contiene una mezcla de terminaciones de línea LF y CRLF.

Finalmente, creo que la recomendación de simplemente "usar lo que se te da" y usar líneas terminadas LF en Windows causará más problemas de los que resuelve. Git tiene las opciones anteriores para tratar de manejar las terminaciones de línea de una manera sensata, por lo que tiene sentido usarlas.

El uso core.autocrlf=falsedetuvo la marca de todos los archivos como actualizados tan pronto como los revisé en mi Visual Studio 2010 proyecto de . Los otros dos miembros del equipo de desarrollo también están utilizando sistemas Windows, por lo que no entró en juego un entorno mixto, sin embargo, la configuración predeterminada que vino con el repositorio siempre marcó todos los archivos como actualizados inmediatamente después de la clonación.

Supongo que la conclusión es encontrar qué configuración de CRLF funciona para su entorno. Especialmente porque en muchos otros repositorios en nuestra configuración de cajas de Linuxautocrlf = true produce mejores resultados.

Más de 20 años después y todavía estamos lidiando con disparidades de final de línea entre sistemas operativos ... triste.

Estas son las dos opciones para usuarios de Windows y Visual Studio que comparten código con usuarios de Mac o Linux . Para una explicación extendida, lea el manual de gitattributes .

* texto = auto

En el .gitattributesarchivo de su repositorio agregue:

*   text=auto

Esto normalizará todos los archivos con LFterminaciones de línea en el repositorio.

Y dependiendo de su sistema operativo ( core.eolconfiguración), los archivos en el árbol de trabajo se normalizarán LFpara sistemas basados ​​en Unix o CRLFpara sistemas Windows.

Esta es la configuración que utilizan los repositorios de Microsoft .NET .

Ejemplo:

Hello\r\nWorld

Se normalizará en el repositorio siempre como:

Hello\nWorld

Al finalizar la compra, el árbol de trabajo en Windows se convertirá a:

Hello\r\nWorld

Al finalizar la compra, el árbol de trabajo en Mac se dejará como:

Hello\nWorld

Nota: Si su repositorio ya contiene archivos no normalizados, git statusmostrará estos archivos como modificados por completo la próxima vez que realice algún cambio en ellos, y podría ser una molestia para otros usuarios fusionar sus cambios más tarde. Consulte la actualización de un repositorio después de cambiar los finales de línea para obtener más información.

core.autocrlf = true

Si textno se especifica en el .gitattributesarchivo, Git usa la core.autocrlfvariable de configuración para determinar si el archivo debe convertirse.

Para los usuarios de Windows, git config --global core.autocrlf truees una excelente opción porque:

• Los archivos se normalizan a LFfinales de línea solo cuando se agregan al repositorio. Si hay archivos no normalizados en el repositorio, esta configuración no los tocará.
• Todos los archivos de texto se convierten en CRLFfinales de línea en el directorio de trabajo.

El problema con este enfoque es que:

• Si es un usuario de Windows autocrlf = input, verá un montón de archivos con LFterminaciones de línea. No es un peligro para el resto del equipo, porque sus compromisos aún se normalizarán con los LFfinales de línea.
• Si es un usuario de Windows core.autocrlf = false, verá un montón de archivos con LFterminaciones de línea y puede introducir archivos con CRLFterminaciones de línea en el repositorio.
• La mayoría de los usuarios de Mac usan autocrlf = inputy pueden obtener archivos con CRLFterminaciones de archivo, probablemente de usuarios de Windows con core.autocrlf = false.

--- ACTUALIZACIÓN 3 --- (no entra en conflicto con ACTUALIZACIÓN 2)

Teniendo en cuenta el caso en que los usuarios de Windows prefieren trabajar CRLFy los usuarios de Linux / Mac prefieren trabajar en LFarchivos de texto. Proporcionando la respuesta desde la perspectiva de un mantenedor de repositorio :

Para mí, la mejor estrategia (menos problemas para resolver) es: mantener todos los archivos de texto con el LFrepositorio de git interno, incluso si está trabajando en un proyecto solo para Windows. Luego, dé a los clientes la libertad de trabajar en el estilo de final de línea de su preferencia , siempre que elijan uncore.autocrlf valor de propiedad que respete su estrategia (LF en el repositorio) mientras preparan los archivos para la confirmación.

La estadificación es lo que muchas personas confunden cuando intentan comprender cómo las estrategias de nueva línea funcionan las . Es esencial comprender los siguientes puntos antes de elegir el valor correcto para la core.autocrlfpropiedad:

• Agregar un archivo de texto para commit ( organizarlo ) es como copiar el archivo a otro lugar dentro del .git/subdirectorio con terminaciones de línea convertidas (dependiendo decore.autocrlf valor en la configuración de su cliente). Todo esto se hace localmente.
• ajuste core.autocrlf es como proporcionar una respuesta a la pregunta (exactamente la misma pregunta en todos los sistemas operativos):
  • "Debería git-client a. Convertir LF-a-CRLF al retirar (extraer) los cambios de repositorio desde el control remoto o b. Convertir CRLF-a-LF al agregar un archivo para confirmación? " Y las posibles respuestas (valores) son:
  • false:" no hacer ninguno de lo anterior ",
  • input:" hacer solo b "
  • true: " hacer ayb "
  • tenga en cuenta que NO hay " hacer solo un "

por suerte

• los valores predeterminados del cliente git (windows:, core.autocrlf: truelinux / mac:) core.autocrlf: falseserán compatibles con la estrategia LF-only-repo .
  Significado : los clientes de Windows convertirán de forma predeterminada a CRLF al retirar el repositorio y a LF al agregar para confirmar. Y los clientes de Linux por defecto no harán ninguna conversión. Esto teóricamente mantiene su repositorio solo para lf.

Desafortunadamente:

• Puede haber clientes GUI que no respeten el core.autocrlfvalor git
• Puede haber personas que no usan un valor para respetar su estrategia de repositorio. Por ejemplo, usan core.autocrlf=falsey agregan un archivo con CRLF para commit.

Para detectar los archivos de texto ASAP no-lf confirmados por los clientes anteriores , puede seguir lo que se describe en --- actualización 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, en un cliente compilado usando: --with-libpcreflag)

Y aquí está la trampa: . Yo, como mantenedor de repositorios, mantengo un git.autocrlf=inputarchivo para poder reparar cualquier archivo comprometido incorrectamente simplemente agregándolos nuevamente para confirmar. Y proporciono un texto de confirmación: "Arreglando archivos incorrectamente comprometidos".

Por lo que .gitattributesse refiere. No cuento con eso, porque hay más clientes ui que no lo entienden. Solo lo uso para proporcionar sugerencias para archivos de texto y binarios, y tal vez marque algunos archivos excepcionales que en todas partes deben mantener los mismos finales de línea:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Pregunta: ¿Pero por qué nos interesa en absoluto la estrategia de manejo de nueva línea?

Respuesta: Para evitar una confirmación de cambio de una sola letra, aparece como un cambio de 5000 líneas , solo porque el cliente que realizó el cambio convirtió automáticamente el archivo completo de crlf a lf (o lo contrario) antes de agregarlo para la confirmación. Esto puede ser bastante doloroso cuando hay una resolución de conflicto involucrada. O podría en algunos casos ser la causa de conflictos irrazonables.

--- ACTUALIZACIÓN 2 ---

Los defectos de git client funcionarán en la mayoría de los casos. Incluso si solo tiene clientes de Windows, clientes de Linux o ambos. Estos son:

• windows: core.autocrlf=true significa convertir líneas a CRLF al finalizar la compra y convertir líneas a LF al agregar archivos.
• Linux: core.autocrlf=input significa no convertir líneas al finalizar la compra (no es necesario, ya que se espera que los archivos se confirmen con LF) y convertir líneas a LF (si es necesario) al agregar archivos. ( - update3 - : Parece que esto es falsepor defecto, pero nuevamente está bien)

La propiedad se puede establecer en diferentes ámbitos. Sugeriría establecer explícitamente en el --globalalcance, para evitar algunos problemas de IDE descritos al final.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

También desaconsejaría usarlo en Windows git config --global core.autocrlf false (en caso de que solo tenga clientes de Windows) en contraste con lo que se propone para la documentación de git . Establecer en falso confirmará los archivos con CRLF en el repositorio. Pero realmente no hay razón. Nunca se sabe si tendrá que compartir el proyecto con los usuarios de Linux. Además, es un paso adicional para cada cliente que se une al proyecto en lugar de usar valores predeterminados.

Ahora, para algunos casos especiales de archivos (p *.bat *.sh. Ej. ) Que desea que se desprotejan con LF o con CRLF, puede usar.gitattributes

Para resumir, la mejor práctica es:

• Asegúrese de que cada archivo no binario se confirme con LF en git repo (comportamiento predeterminado).
• Utilice este comando para asegurarse de que no hay archivos están comprometidos con CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Nota: en los clientes de Windows funciona sólo a través de git-bashy en los clientes de Linux sólo si compilado utilizando --with-libpcreen./configure ).
• Si encuentra alguno de estos archivos ejecutando el comando anterior, corríjalos. Esto implica (al menos en Linux):
  • conjunto core.autocrlf=input( --- actualización 3 - )
  • cambiar el archivo
  • revertir el cambio (el archivo todavía se muestra como modificado)
  • comprometerlo
• Use solo el mínimo .gitattributes
• Indique a los usuarios que establezcan lo core.autocrlfdescrito anteriormente en sus valores predeterminados.
• No cuente al 100% con la presencia de .gitattributes. Los git-clients de IDEs pueden ignorarlos o tratarlos de manera diferente.

Como se dijo, algunas cosas se pueden agregar en los atributos de git:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Creo que algunas otras opciones seguras para en .gitattributeslugar de utilizar la detección automática de archivos binarios:

• -text(por ejemplo, para *.zipo *.jpgarchivos: no se tratará como texto. Por lo tanto, no se intentarán conversiones de final de línea. La diferencia podría ser posible a través de programas de conversión)
• text !eol(por ejemplo *.java, para *.html: tratado como texto, pero la preferencia de estilo de eol no está establecida. Por lo tanto, se usa la configuración del cliente)
• -text -diff -merge(por ejemplo, para *.hugefile: No se trata como texto. No es posible la diferencia / fusión)

--- ACTUALIZACIÓN ANTERIOR ---

Un ejemplo doloroso de un cliente que confirmará los archivos incorrectamente:

netbeans 8.2 (en Windows), confirmará erróneamente todos los archivos de texto con CRLF, a menos que lo haya establecido explícitamente core.autocrlfcomo global . Esto contradice el comportamiento estándar del cliente git y causa muchos problemas más tarde, al actualizar / fusionar. Esto es lo que hace que algunos archivos parezcan diferentes (aunque no lo son) incluso cuando revierte .
El mismo comportamiento en netbeans ocurre incluso si ha agregado correctamente.gitattributes a su proyecto.

El uso del siguiente comando después de una confirmación, al menos lo ayudará a detectar temprano si su repositorio git tiene problemas de finalización de línea: git grep -I --files-with-matches --perl-regexp '\r' HEAD

He pasado horas para encontrar el mejor uso posible .gitattributes, para finalmente darme cuenta, que no puedo contar con eso.
Desafortunadamente, mientras existan editores basados ​​en JGit (que no se pueden manejar .gitattributescorrectamente), la solución segura es forzar LF en todas partes, incluso a nivel de editor.

Use los siguientes anti-CRLFdesinfectantes.

• Clientes Windows / Linux: core.autocrlf=input

• comprometido .gitattributes: * text=auto eol=lf

• comprometido .editorconfig( http://editorconfig.org/ ) que es un tipo de formato estandarizado, combinado con complementos de editor:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Esta es solo una solución alternativa :

En casos normales, use las soluciones que se envían con git. Estos funcionan muy bien en la mayoría de los casos. Forzar a LF si comparte el desarrollo en sistemas basados ​​en Windows y Unix configurando .gitattributes .

En mi caso, había> 10 programadores desarrollando un proyecto en Windows. Este proyecto se registró con CRLF y no había opción de forzar a LF.

Algunas configuraciones fueron escritas internamente en mi máquina sin ninguna influencia en el formato LF; así, algunos archivos se cambiaron globalmente a LF en cada cambio de archivo pequeño.

Mi solución:

Máquinas Windows: Deje todo como está. No le importa nada, ya que usted es un desarrollador predeterminado de Windows 'Lone Wolf' y tiene que manejar así: "No hay otro sistema en el mundo, ¿verdad?"

Máquinas Unix

1. Agregue las siguientes líneas a la [alias]sección de una configuración . Este comando enumera todos los archivos modificados (es decir, modificados / nuevos):

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Convierta todos esos archivos modificados en formato DOS:

   unix2dos $(git lc)

3. Opcionalmente ...

   1. Crea un gancho git para esta acción para automatizar este proceso

   2. Use params e inclúyalo y modifique la grepfunción para que coincida solo con nombres de archivos particulares, por ejemplo:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Siéntase libre de hacerlo aún más conveniente utilizando un atajo adicional:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... y dispara las cosas convertidas escribiendo

      git c2dos