Pregunta ¿Cuál es la mejor estrategia de manejo de CRLF (retorno de carro, avance de línea) con Git?


Traté de enviar archivos con líneas CRLF, pero falló.

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

Por favor comparta solo una mejor práctica por respuesta.


543
2017-10-04 20:39


origen


Respuestas:


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

Ver los detalles en github: ayudaguía de Tratando con finales de línea.

Git te permite establecer las propiedades de final de línea para un   Repo directamente utilizando el atributo de texto en el    .gitattributes archivo. Este archivo está comprometido con   el repositorio y anula el core.autocrlf ajuste,   lo que le permite garantizar un comportamiento constante para todos   usuarios independientemente de su configuración de git.

Y por lo tanto

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

Aquí hay un ejemplo de .gitattributes archivo

# 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 un conveniente colección de archivos .gitattributes listos para usar para los lenguajes de programación más populares. Es útil para empezar.

Una vez que haya creado o ajustado su .gitattributes, deberías realizar una vez y para siempre re-normalización de finales de línea.

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

Finalmente, el Cuidado con el final de tu línea artículo proporciona más antecedentes y explica cómo Git ha evolucionado en los asuntos a mano. Considero esto lectura obligatoria.

Probablemente tenga usuarios en su equipo que utilicen EGit o JGit (herramientas como Eclipse y TeamCity los usen) para confirmar sus cambios. Entonces estás de suerte, como @gatinueta explicó en los comentarios de esta respuesta:

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

Un truco podría ser hacer que ellos confirmen sus cambios en otro cliente, digamos SourceTree. Nuestro equipo entonces prefería esa herramienta a Eit de Eclipse para muchos casos de uso.

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


683
2018-06-01 18:56



No convierta las terminaciones de línea. El trabajo del VCS no es interpretar los datos, solo almacenarlos y versionarlos. Cada editor de texto moderno puede leer ambos tipos de terminaciones de línea de todos modos.


98
2017-10-04 20:42



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

Un poco de contexto adicional a continuación:

Debe ser cualquiera core.autocrlf=true Si te gusta   Final de DOS o core.autocrlf=input si tu prefieres   unix-newlines. En ambos casos, su repositorio de Git se   tener solo LF, que es lo correcto. Lo único   argumento para core.autocrlf=false fue eso automático   heurística puede detectar incorrectamente algunos binarios como texto   y luego su tesela se corromperá. Asi que,    core.safecrlf opción fue introducida para advertir a un usuario si   se produce un cambio irreversible. De hecho, hay dos   posibilidades de cambios irreversibles - mixto   final de línea en el archivo de texto, en esta normalización es   deseable, por lo que esta advertencia puede ignorarse, o   (muy poco probable) que Git detectó incorrectamente su   archivo binario como texto. Entonces necesitas usar atributos para   Dile a Git que este archivo es binario.

El párrafo anterior fue originalmente extraído de un hilo en gmane.org, pero desde entonces ha desaparecido.


76
2017-07-10 22:36



Dos estrategias alternativas para ser consistente sobre terminaciones de línea en entornos mixtos (Microsoft + Linux + Mac):

Un global por configuración de todos los repositorios

1) Convertir formato todo a uno

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

2) Establecer core.autocrlf a input en Linux / UNIX o true en MS Windowns (repositorio o global)

git config --global core.autocrlf input

3) [Opcional] establecer core.safecrlf a true (para detener) o warn (para cantar :) para agregar protector extra comparando si la transformación de línea nueva invertida daría como resultado el mismo archivo

git config --global core.safecrlf true


B. O por configuración de repositorio

1) Convertir formato todo a uno

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

2) agregar .gitattributes archivo a su repositorio

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

No te preocupes por tus archivos binarios: Git debería ser lo suficientemente inteligente acerca de ellos.


Más sobre las variables safecrlf / autocrlf


53
2018-06-26 01:18



Intenta configurar el core.autocrlf opción de configuración para true. También eche un vistazo a la core.safecrlf opción.

En realidad, suena como core.safecrlf puede que ya esté 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, entonces tal vez quiera 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íneas LF y CRLF.

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


11
2017-10-05 03:50



Utilizando core.autocrlf=false detuvo todos los archivos de ser marcados actualizados tan pronto como los revisé en mi Visual Studio 2010 proyecto. Los otros dos miembros del equipo de desarrollo también usan sistemas de Windows, por lo que no entraron en juego entornos mixtos, pero la configuración predeterminada que acompañaba al repositorio siempre marcaba todos los archivos como actualizados inmediatamente después de la clonación.

Supongo que la conclusión es encontrar qué configuración CRLF funciona para su entorno. Especialmente desde muchos otros repositorios en nuestra configuración de cajas de Linux autocrlf = trueproduce mejores resultados

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


9
2018-03-16 03:10



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

* text = auto

En su repositorio .gitattributes archivo agregar:

*   text=auto

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

Y dependiendo de su sistema operativo (core.eol configuración), los archivos en el árbol de trabajo se normalizarán para LF para sistemas basados ​​en Unix o CRLF para sistemas Windows.

Esta es la configuración que Microsoft .NET uso de repos.

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á en:

Hello\r\nWorld

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

Hello\nWorld

Nota: si su repositorio ya contiene archivos no normalizados, git status mostrará estos archivos como completamente modificados 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 adelante. Ver actualizar un repositorio después de cambiar los finales de línea para más información.

core.autocrlf = true

Si text no se especifica en el .gitattributes archivo, Git usa el core.autocrlf variable de configuración para determinar si el archivo debe convertirse.

Para usuarios de Windows, git config --global core.autocrlf true es una gran opción porque:

  • Los archivos están normalizados para LF finales de línea solo cuando se agrega al repositorio. Si hay archivos no normalizados en el repositorio, esta configuración no los tocará.
  • Todos los archivos de texto se convierten a CRLF terminaciones de línea en el directorio de trabajo.

El problema con este enfoque es que:

  • Si eres un usuario de Windows con autocrlf = input, verá un montón de archivos con LF finales de línea. No es un peligro para el resto del equipo, porque tus compromisos se normalizarán con LF finales de línea.
  • Si eres un usuario de Windows con core.autocrlf = false, verá un montón de archivos con LF finales de línea y puede presentar archivos con CRLF terminaciones de línea en el repositorio.
  • La mayoría de los usuarios de Mac usan autocrlf = input y puede obtener archivos con CRLF finales de archivos, probablemente de usuarios de Windows con core.autocrlf = false.

5
2018-02-14 23:02



Esto es solo un solución alternativa solución:

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

En mi caso, había> 10 programadores desarrollando un proyecto en Windows. Este proyecto se verificó 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; por lo tanto, algunos archivos se cambiaron globalmente a LF en cada cambio de archivo pequeño.

Mi solución:

Máquinas de Windows: Deja todo tal como es. No se preocupe por nada, ya que usted es un desarrollador predeterminado de windows 'lone wolf' y debe manejarlo de la siguiente manera: "No hay otro sistema en el mundo, ¿verdad?"

Unix-Machines

  1. Agregue las siguientes líneas a la configuración [alias] secció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. Convierte todos esos cambiado archivos en formato dos:

    unix2dos $(git lc)
    
  3. Opcionalmente ...

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

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

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
      
    3. No dude en hacerlo aún más conveniente mediante el uso de un atajo adicional:

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

      ... y dispara las cosas convertidas tecleando

      git c2dos
      

5
2018-03-20 15:21



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

Use la siguiente anti-CRLF desinfectantes.

--- Actualización ---

Incluso si no quieres usar la estrategia anterior, el siguiente comando es tu amigo (Nota: en Windows, los clientes solo funcionan a través de git-bash y en clientes de Linux solo si se compila usando --with-libpcre en ./configure)

# Print all files that have been committed with CRLF (more correctly that contain CR), so that you normalize them.
git grep -I --files-with-matches --perl-regexp '\r' HEAD

Uno ejemplo doloroso:

netbeans 8.2 (en Windows), cometerá incorrectamente todos los archivos de texto con CRLF en repos, a no ser que tienes explícitamente conjunto core.autocrlf como global. Esto contradice el comportamiento del cliente estándar de Git, y causa muchos problemas más adelante, mientras se actualiza / se fusiona. Esto es lo que hace que algunos los archivos aparecen diferentes (aunque no lo son) incluso cuando reviertes.
El mismo comportamiento en netbeans sucede incluso si ha agregado correcto .gitattributes a tu proyecto

Usar el comando anterior después de una confirmación, al menos lo ayudará a detectar temprano si su repositorio de git tiene problemas para terminar la línea.


1
2017-09-21 15:17