Git: Eliminar retornos de carro de archivos controlados por código fuente

Question

Tengo un repositorio Git que tiene algunos archivos con formato DOS (\r\n terminaciones de línea). Me gustaría simplemente ejecutar los archivos a través del dos2unix (que cambiaría todos los archivos al formato UNIX, con \n terminaciones de línea), pero ¿qué tan grave afectaría esto a la historia, y se recomienda en absoluto?

Supongo que el estándar es usar siempre terminaciones de línea UNIX para archivos controlados por fuente, y opcionalmente cambiar a terminaciones de línea específicas del sistema operativo localmente?

Answer 1

El enfoque que deberá usar depende de qué tan público sea su repositorio.

Si no te importa o te importa cambiar todos los SHA porque eres más o menos el único que lo usa pero quieres tener este problema resuelto para siempre, puedes ejecutar git filter-branch y aplicar dos2unix a todos archivos en cada commit. (Si comparte el repositorio, todos los demás necesitan más o menos para renovarlo por completo, así que esto es potencialmente peligroso.)

Por lo tanto, la mejor opción y también una manera más fácil sería cambiarla solo en las cabeceras actuales . Esto significa que tus commits pasados ​​aún tienen terminaciones de \r\n, pero a menos que estés haciendo mucho picking desde el pasado, esto no debería ser un problema. Las herramientas de diferencias pueden quejarse un poco más a menudo, por supuesto, pero normalmente solo se difieren con confirmaciones en las cercanías, por lo que este problema se resuelve a medida que se acumulan las confirmaciones.

Y los finales de línea UNIX son estándar, tiene razón al respecto. El mejor enfoque es configurar su editor para que solo escriba estos finales, incluso en Windows. De lo contrario, también hay una configuración de autocrlf que puede usar.

---

Además de la historia reescribir parte:

La última vez que hice lo mismo, que utiliza el siguiente comando para cambiar todos los archivos a los finales de Unix.

#!/bin/bash 
all2dos() { find * -exec dos2unix {} \; } 
export -f all2dos 
git filter-branch -f --tree-filter 'all2dos' --tag-name-filter cat --prune-empty -- --all 

Answer 2

Para la solución continua, echar un vistazo a la core.autocrlf (y core.safecrlf) config parameters.

Hacer esto una vez para todo su repositorio creará un compromiso que es bastante imposible combinar (ya que cada línea en esos archivos se modificará), pero una vez que lo supere, no debería ser un gran problema. (Sí, podría usar git filter-branch para hacer la modificación a lo largo de la historia, pero eso da un poco de miedo.)

Answer 3

Esta crlf cosa nos volvió locos cuando convertimos de svn a git (en una central (pelada)) entorno scm. Lo que finalmente nos consiguió fue que copiamos el archivo global .gitconfig en la raíz de usuario de todos (sí, tanto Windows como Linux) con el inicial proveniente de un sistema Windows y teniendo core.autocrlf = true y core.safecrlf = false que causó estragos en los usuarios de Linux (como las secuencias de comandos bash no funcionó y todos esos horribles^M). Entonces, inicialmente hicimos una secuencia de comandos de clonación y de salida que hizo un dos2unix después de estos comandos. Luego me encontré con los elementos de configuración core.autocrlf y core.safecrlf y los configuré en función de O/S:

Windows: core.autocrlf = true y core.safecrlf = false Linux: core.autocrlf = input y núcleo.safecrlf = false

Estos fueron montarse con: --- --- en Windows

git config --global core.autocrlf true 
git config --global core.safecrlf false 

--- --- en Linux

git config --global core.autocrlf input 
git config --global core.safecrlf false 

Entonces para nuestros desarrolladores de Linux que la configuración un pequeño script bash/usr/local/bin/gitfixcrlf:

#!/bin/sh 
# remove local tree 
git ls-files -z | xargs -0 rm 
# checkout with proper crlf 
git checkout . 

que sólo tuvieron que correr en su local de sa ndbox clones una vez. Cualquier clonación futura se realizó correctamente. Cualquier empuje futuro ahora se manejó correctamente. Por lo tanto, esto resolvió nuestros múltiples problemas de O/S con avances de línea. También tenga en cuenta que Mac tiene la misma configuración que Linux.

Answer 4

Si su lista de archivos del control de versiones incluye binarios, o no se puede cambiar fácilmente la historia ... aquí es un práctico dandi de una sola línea:

https://unix.stackexchange.com/a/365679/112190