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

¿Cómo difiere uno con la versión anterior?

¿Hay una opción como "tratar ^ M como nueva línea al diferenciar"?

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 Ruby 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

GitHub sugiere que debe asegurarse de usar solo \ n como un carácter de nueva línea en repositorios manejados por git. Hay una opción para convertir automáticamente:

$ git config --global core.autocrlf true

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

Y luego convierta sus 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 del manual .

Desarrollando en Windows, me encontré con este problema cuando lo uso 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 ^Mpersonajes ya no aparecen al final de las líneas de git diff, git show, etc.

Parece dejar otras configuraciones tal cual; por ejemplo, los espacios adicionales al final de una línea todavía 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 de un solo proyecto, omita el --global.)

EDITAR :

Después de muchas dificultades en el final de línea, he tenido la mejor suerte, cuando trabajo en un equipo .NET, con esta configuración:

• NO configuración core.eol
• NO configuración core.whitespace
• NO configuración core.autocrlf
• Al ejecutar el instalador de Git para Windows, obtendrá estas tres opciones:
  • Verifique el estilo de Windows, confirme los finales de línea de estilo Unix <- elija este
  • Pague como está, confirme los finales de línea de estilo Unix
  • Realizar el pago tal cual, confirmar tal cual

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

git config core.whitespace cr-at-eol

Si necesita eliminar algunas configuraciones del núcleo. *, La forma más fácil es ejecutar este comando:

git config --global -e

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

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

Ver también:

core.whitespace = cr-at-eol

o equivalente,

[core]
    whitespace = cr-at-eol

donde whitespaceestá precedido por un carácter de tabulación .

¿Por qué tienes estos ^Men tu git diff?

En mi caso, estaba trabajando en un proyecto que se desarrolló en Windows y usé OS X. Cuando cambié algún código, vi ^Mal final de las líneas que agregué git diff. Creo que ^Mestaban apareciendo porque eran terminaciones de línea diferentes que el resto del archivo. Debido a que el resto del archivo se desarrolló en Windows, usó CRterminaciones de línea, y en OS X usa LFterminaciones de línea.

Aparentemente, el desarrollador de Windows no usó la opción " Checkout estilo Windows, confirmar terminaciones de línea estilo Unix " durante la instalación de Git.

Entonces, ¿qué debemos hacer al respecto?

Puede hacer que los usuarios de Windows reinstalen git y usen la opción " Finalizar línea al estilo de Windows, confirmar estilo Unix ". Esto es lo que preferiría, porque veo a Windows como una excepción en sus caracteres de final de línea y Windows soluciona su propio problema de esta manera.

Sin embargo, si opta por esta opción, debe corregir los archivos actuales (porque todavía usan los CRfinales de línea). 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 .gitattributesarchivo que haga cumplir ciertos archivos para usar LFcomo terminaciones de línea. Pon esto en el archivo:

   *.ext text eol=crlf
   

   Reemplace .extcon las extensiones de archivo que desea hacer coincidir.

3. Agregue todos los archivos nuevamente.

   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 .gitattributesarchivo a menos que tenga usuarios obstinados de Windows que no quieran usar la opción " Finalizar línea estilo Confirmar Windows, confirmar estilo Unix ".

5. Comprometerse y empujarlo todo.

6. Elimine y revise los archivos aplicables en todos los sistemas donde se usan. En los sistemas Windows, asegúrese de que ahora usen la opción " Finalizar línea al estilo de Windows, confirmar estilo Unix ". También debe hacer esto en el sistema donde ejecutó estas tareas porque cuando agregó los archivos, git dijo:

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

   Puede hacer algo como esto para eliminar los archivos:

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

   Y luego esto para recuperarlos con las terminaciones de línea correctas:

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

   Por supuesto, reemplazando .extcon la extensión que desee.

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

La otra opción es hacer cumplir las terminaciones de línea de estilo de Windows. También puede usar el .gitattributesarchivo para esto.

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

¿Hay una opción como "tratar ^ M como nueva línea al diferenciar"?

Habrá uno con Git 2.16 (Q1 2018), ya que la " diff" familia de comandos 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- en commit 10f65c2 , 27 nov 2017)}

diff: --ignore-cr-at-eol

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

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

TL; DR

Cambie el código fuente core.pagera "tr -d '\r' | less -REX", no

Esta es la razón por

Los molestos ^ M que se muestran son un artefacto de la coloración y el localizador. Es causado por less -Runa opción predeterminada de buscapersonas git. (el localizador predeterminado de git es less -REX)

Lo primero a tener en cuenta es que git diff -bno 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 las terminaciones 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 habilita el color y less -Rsí:

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 solución se muestra usando una tubería 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

Es una alternativa imprudente usar less -r, porque pasará por todos los códigos de control, no solo los códigos de color.

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

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

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

En lugar de escribir:

git diff <commitHash> <filename>

tratar:

git difftool <commitHash> <filename>

En mi caso, lo que hizo fue este comando:

git config  core.whitespace cr-at-eol

Fuente: https://public-inbox.org/git/8d7e4807-9a79-e357-8265-95f22ab716e0@web.de/T/

Como señaló VonC, esto ya se ha incluido en git 2.16+. Desafortunadamente, el nombre de la opción ( --ignore-cr-at-eol) difiere del utilizado por GNU diff al que estoy acostumbrado ( --strip-trailing-cr).

Cuando me enfrenté a este problema, mi solución fue invocar la diferencia de GNU en lugar de la diferencia incorporada de git, porque mi git es anterior a 2.16. Lo hice usando esta línea de comando:

GIT_EXTERNAL_DIFF='diff -u --strip-trailing-cr "$2" "$5";true;#' git diff --ext-diff

Eso permite usar --strip-trailing-cry cualquier otra opción de GNU diff.

También hay esta otra manera:

git difftool -y -x 'diff -u --strip-trailing-cr'

pero no usa la configuración de buscapersonas configurada, por eso prefiero la primera.