should - git-diff para ignorar ^ M

git new line settings

Question

En un proyecto donde algunos de los archivos contienen ^ M como separadores de nueva línea. Difundir estos archivos es aparentemente imposible, ya que git-diff lo ve ya que todo el archivo es solo una línea.

¿Cómo se diferencia uno con la versión anterior?

¿Existe una opción como "tratar ^ M como nueva línea cuando esté difiriendo"?

prompt> git-diff "HEAD^" -- MyFile.as 
diff --git a/myproject/MyFile.as b/myproject/MyFile.as
index be78321..a393ba3 100644
--- a/myproject/MyFile.cpp
+++ b/myproject/MyFile.cpp
@@ -1 +1 @@
-<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
/ No newline at end of file
+<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
/ No newline at end of file
prompt>

ACTUALIZAR:

ahora he escrito un script que revisa las últimas 10 revisiones y convierte CR a LF.

require ''fileutils''

if ARGV.size != 3
  puts "a git-path must be provided"
  puts "a filename must be provided"
  puts "a result-dir must be provided"
  puts "example:"
  puts "ruby gitcrdiff.rb project/dir1/dir2/dir3/ SomeFile.cpp tmp_somefile"
  exit(1)
end

gitpath = ARGV[0]
filename = ARGV[1]
resultdir = ARGV[2]

unless FileTest.exist?(".git")
  puts "this command must be run in the same dir as where .git resides"
  exit(1)
end

if FileTest.exist?(resultdir)
  puts "the result dir must not exist"
  exit(1)
end
FileUtils.mkdir(resultdir)

10.times do |i|
  revision = "^" * i
  cmd = "git show HEAD#{revision}:#{gitpath}#{filename} | tr ''//r'' ''//n'' > #{resultdir}/#{filename}_rev#{i}"
  puts cmd 
  system cmd
end

Answer 1

¿Existe una opción como "tratar ^ M como nueva línea cuando esté difiriendo"?

Habrá uno con Git 2.16 (Q1 2018), ya que la familia de comandos " diff " aprendió a ignorar las diferencias en el retorno de carro al final de la línea.

Ver commit e9282f0 (26 de octubre de 2017) por Junio ​​C Hamano ( gitster ) .
Ayudado por: Johannes Schindelin ( dscho ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 10f65c2 , 27 de noviembre de 2017)}

dif: --ignore-cr-at-eol

Una nueva opción --ignore-cr-at-eol le dice a la maquinaria de diferencias que trate un retorno de carro al final de una línea (completa) como si no existiera.

Al igual que otras opciones " --ignore-* " para ignorar varios tipos de diferencias de espacios en blanco, esto ayudará a revisar los cambios reales que realizó sin que se distraiga con la falsa conversión de CRLF<->LF realizada por su programa editor.

Answer 2

¿Por qué obtienes estos ^M en tu git diff ?

En mi caso, estaba trabajando en un proyecto que se desarrolló en Windows y usé OS X. Cuando cambié un código, vi ^M al final de las líneas que agregué en git diff . Creo que los ^M estaban apareciendo porque eran finales de línea diferentes al resto del archivo. Debido a que el resto del archivo se desarrolló en Windows, se utilizaron los finales de línea CR , y en OS X se utilizan los finales de línea LF .

Aparentemente, el desarrollador de Windows no usó la opción " Realizar el final del estilo de Unix al estilo de Windows, confirmar los finales de línea de Unix " durante la instalación de Git.

Entonces, ¿qué debemos hacer al respecto?

Puede hacer que los usuarios de Windows vuelvan a instalar git y utilicen la opción " Realizar el checkout del estilo de Windows, confirme los finales de línea de estilo Unix ". Esto es lo que preferiría, porque veo a Windows como una excepción en su línea de fin de caracteres y Windows soluciona su propio problema de esta manera.

Si opta por esta opción, sin embargo, debería corregir los archivos actuales (porque todavía están usando los finales de línea CR ). Hice esto siguiendo estos pasos:

1. Elimine todos los archivos del repositorio, pero no de su sistema de archivos.

   git rm --cached -r .

2. Agregue un archivo .gitattributes que obligue a ciertos archivos a usar un LF como finales de línea. Pon esto en el archivo:

   *.ext text eol=crlf

   Reemplace .ext con las extensiones de archivo que desea hacer coincidir.

3. Agrega todos los archivos de nuevo.

   git add .

   Esto mostrará mensajes como este:

   warning: CRLF will be replaced by LF in <filename>.
   The file will have its original line endings in your working directory.

4. Puede eliminar el archivo .gitattributes menos que tenga usuarios obstinados de Windows que no quieran usar la opción " Finalizar el estilo de Windows, comprometer los finales de línea de estilo Unix ".

5. Comprométete y empújalo todo.

6. Elimine y revise los archivos aplicables en todos los sistemas donde se utilizan. En los sistemas Windows, asegúrese de que ahora usen la opción " Finalizar el estilo de Unix, confirme los finales de línea del estilo Unix ". También debes hacer esto en el sistema donde ejecutaste estas tareas porque cuando agregaste los archivos, git dijo:

   The file will have its original line endings in your working directory.

   Puedes hacer algo como esto para eliminar los archivos:

   git ls | grep ".ext$" | xargs rm -f

   Y luego esto para recuperarlos con los finales de línea correctos:

   git ls | grep ".ext$" | xargs git checkout

   Por supuesto reemplazando .ext con la extensión que quieras.

Ahora su proyecto solo usa caracteres LF para los finales de línea, y los desagradables caracteres CR nunca volverán :).

La otra opción es hacer cumplir los finales de línea de estilo de Windows. También puede usar el archivo .gitattributes para esto.

Más información: https://help.github.com/articles/dealing-with-line-endings/#platform-all

Answer 3

Al desarrollar en Windows, me encontré con este problema al usar git tfs . Lo resolví de esta manera:

git config --global core.whitespace cr-at-eol

Básicamente, esto le dice a Git que un CR de fin de línea no es un error. Como resultado, esos molestos caracteres ^M ya no aparecen al final de las líneas en git diff , git show , etc.

Parece que deja otras configuraciones como están; por ejemplo, los espacios adicionales al final de una línea aún se muestran como errores (resaltados en rojo) en la diferencia.

(Otras respuestas han aludido a esto, pero lo anterior es exactamente cómo establecer la configuración. Para establecer la configuración para un solo proyecto, omita el --global ).

EDITAR :

Después de muchos problemas de final de línea, tuve la mejor suerte, cuando trabajé en un equipo de .NET, con estos ajustes:

• NO ajuste core.eol
• NO ajuste de core.whitespace
• NO ajuste core.autocrlf
• Cuando ejecute el instalador de Git para Windows, obtendrá estas tres opciones:
  • Compruebe el estilo de Windows, confirme los finales de línea de estilo Unix <- elija este
  • Verifique como está, confirme los finales de línea de estilo Unix
  • Pago como está, cometer como está

Si necesita usar la configuración de espacios en blanco, probablemente debería habilitarla solo por proyecto si necesita interactuar con TFS. Simplemente omita el --global

git config core.whitespace cr-at-eol

Si necesita eliminar algunas configuraciones básicas. *, La forma más sencilla es ejecutar este comando:

git config --global -e

Esto abre su archivo .gitconfig global en un editor de texto, y puede eliminar fácilmente las líneas que desea eliminar. (O puedes poner ''#'' delante de ellos para comentarlos).

Answer 4

Luché con este problema durante mucho tiempo. Con mucho, la solución más sencilla es no preocuparse por los caracteres ^ M y solo usar una herramienta de visualización visual que pueda manejarlos.

En lugar de escribir:

git diff <commitHash> <filename>

tratar:

git difftool <commitHash> <filename>

Answer 5

Pruebe git diff --ignore-space-at-eol , o git diff --ignore-space-change , o git diff --ignore-all-space .

Answer 6

Si está utilizando Eclipse, puede hacer que ^M desaparezca de git diff configurando File > Convert Line Delimiter To > Unix (LF, /n, 0A, ¶)

Answer 7

Ver también:

core.whitespace = cr-at-eol

o equivalente,

[core]
    whitespace = cr-at-eol

donde el whitespace en whitespace está precedido por un carácter de tabulación .

Answer 8

GitHub sugiere que debes asegurarte de usar solo / n como un carácter de nueva línea en los repositorios manejados por git. Hay una opción para auto-convertir:

$ git config --global core.autocrlf true

Por supuesto, se dice que esto convierte crlf a lf, mientras que usted quiere convertir cr a lf. Espero que esto todavía funcione ...

Y luego convierte tus archivos:

# Remove everything from the index
$ git rm --cached -r .

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

core.autocrlf se describe en la página man .

Answer 9

TL; DR

Cambie core.pager a "tr -d ''/r'' | less -REX" , no al código fuente

Esta es la razón por

Esos molestos ^ M que se muestran son un artefacto de la colorización y el paginador. Es causado por less -R , una opción de paginador git predeterminada. (el paginador predeterminado de git es less -REX )

Lo primero que se debe tener en cuenta es que git diff -b no mostrará cambios en el espacio en blanco (por ejemplo, / r / n vs / n)

preparar:

git clone https://github.com/CipherShed/CipherShed
cd CipherShed

Una prueba rápida para crear un archivo Unix y cambiar los finales de línea no mostrará cambios con git diff -b :

echo -e ''The quick brown fox/njumped over the lazy/ndogs.'' > test.txt
git add test.txt
unix2dos.exe test.txt
git diff -b test.txt

Notamos que forzar una tubería a menos no muestra el ^ M, pero habilitando el color y less -R sí:

git diff origin/v0.7.4.0 origin/v0.7.4.1 | less
git -c color.ui=always diff origin/v0.7.4.0 origin/v0.7.4.1 | less -R

La corrección se muestra utilizando un tubo para quitar el / r (^ M) de la salida:

git diff origin/v0.7.4.0 origin/v0.7.4.1
git -c core.pager="tr -d ''/r'' | less -REX"  diff origin/v0.7.4.0 origin/v0.7.4.1

Una alternativa imprudente es usar less -r , porque pasará a través de todos los códigos de control, no solo de los códigos de color.

Si solo quiere editar su archivo de configuración de git directamente, esta es la entrada para actualizar / agregar:

[core]
        pager = tr -d ''//r'' | less -REX