¿Qué significa “1 línea agrega errores de espacio en blanco” al aplicar un parche?

Estoy editando algunos archivos de rebajas de un repositorio remoto clonado y quería probar la creación y aplicación de parches de una rama a otra. Sin embargo, cada vez que hago algún cambio, recibo el siguiente mensaje durante git apply:

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

(Esto está sucediendo en mi Mac y no sé dónde se creó el código original).

¿Qué significa el mensaje de advertencia? ¿Debo preocuparme?

No necesitas preocuparte.

La advertencia establece un estándar de limpieza de archivos de texto con respecto al espacio en blanco, el tipo de cosas que suelen preocupar a muchos programadores. Como explica el manual :

Lo que se considera errores de espacio en blanco se controla mediante la configuración de core.whitespace. De forma predeterminada, los espacios en blanco finales (incluidas las líneas que constan únicamente de espacios en blanco) y un carácter de espacio seguido inmediatamente por un carácter de tabulación dentro de la sangría inicial de la línea se consideran errores de espacio en blanco.

De forma predeterminada, el comando genera mensajes de advertencia pero aplica el parche.

Entonces, el "error" significa que el cambio introduce un espacio en blanco final, una línea de solo espacios en blanco o un espacio que precede a una pestaña. Aparte de ese hecho, no hay nada erróneo en el cambio, y se aplicará de forma limpia y correcta. En otras palabras, si no le importa el espacio en blanco "incorrecto", no dude en ignorar la advertencia o apagarlo con git config apply.whitespace nowarn.

Un caso en el que podría importarle legítimamente es cuando desea diferenciar entre el error de espacio en blanco "antiguo" (que tal vez desee conservar por motivos heredados) y los errores de espacio en blanco "nuevo" (que desea evitar).

A tal efecto, Git 2.5+ (Q2 2015) propondrá una opción más específica para la detección de espacios en blanco.

Consulte las confirmaciones 0e383e1 , 0ad782f y d55ef3e [26 de mayo de 2015] de Junio ​​C Hamano ( gitster) .
^{(Combinado por Junio en el compromiso 709cd91 , 11 de junio de 2015)}

diff.c: --ws-error-highlight=<kind>opción

Tradicionalmente, solo nos preocupamos por las roturas de espacios en blanco introducidas en nuevas líneas.
Algunas personas también quieren pintar roturas de espacios en blanco en líneas antiguas. Cuando ven una rotura de espacios en blanco en una nueva línea, pueden detectar el mismo tipo de rotura de espacios en blanco en la línea anterior correspondiente y quieren decir "Ah, esas roturas están ahí, pero fueron heredadas del original, así que no las toquemos por ahora."

Introducir --ws-error-highlight=<kind>opción, que les permite pasar de una lista separada por comas old, newy contextpara especificar qué líneas a más destacado espacio en blanco en los errores.

La documentación ahora incluye :

--ws-error-highlight=<kind>

Resalte los errores de espacio en blanco en las líneas especificadas por <kind>en el color especificado por color.diff.whitespace.
<kind>es una lista separada por comas de old, new, context.
Cuando no se ofrece esta opción, solo newse resaltan los errores de espacio en blanco en las líneas.

Por ejemplo, --ws-error-highlight=new,oldresalta los errores de espacios en blanco en las líneas eliminadas y agregadas.
allse puede utilizar como una abreviatura de old,new,context.

Por ejemplo, la confirmación anterior tenía un error de espacio en blanco ( bbb), pero puede centrarse solo en los errores nuevos (al final de still bbby ccc):

(prueba hecha después t/t4015-diff-whitespace.sh)

Con Git 2.26 (Q1 2020), la diff-*familia de subcomandos de plomería ahora presta atención a la diff.wsErrorHighlightconfiguración, que se ha ignorado antes; esto permite " git add -p" mostrar también los problemas de espacios en blanco al usuario final.

Consulte la confirmación da80635 (31 de enero de 2020) de Jeff King ( peff) .
^{(Combinado por Junio ​​C Hamano - gitster- en el compromiso df04a31 , 14 de febrero de 2020)}

diff: mueve diff.wsErrorHighlight a la configuración "básica"

^{Firmado por: Jeff King}

Analizamos diff.wsErrorHighlight git_diff_ui_config(), lo que significa que no tiene efecto para los comandos de plomería, solo para las porcelanas como él git diffmismo.
Esto es un poco molesto ya que significa que scripts como add--interactive, que producen una diferencia de color visible para el usuario, no respetan la opción .

Podríamos enseñarle a ese script a analizar la configuración y pasarla --ws-error-highlighta la plomería de diferencias. Pero hay una solución más sencilla.

Debería ser razonablemente seguro para la plomería respetar esta opción, ya que solo se activa cuando el color está habilitado. Y cualquiera que analice la salida coloreada ya debe lidiar con el hecho de que color.diff.*puede cambiar la salida exacta que ve; esas opciones han sido parte de git_diff_basic_config()sus inicios en 9a1805a872 (agregue una devolución de llamada de configuración diferencial "básica", 2008-01-04, Git v1.5.4-rc3).

Así que podemos moverlo a la configuración "básica", que corrige add--interactive, junto con cualquier otro script en el mismo barco, con un riesgo muy bajo de dañar a los usuarios de plomería.

El error de espacio en blanco con imágenes visuales se muestra aquí.

http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines

Porque la línea TABcomienza con is en lugar de SPACE. Vaya al archivo de parche y reemplácelo TABcon SPACE. Por ejemplo, en vim en línea + desde el archivo de parche, escriba x para eliminar el espacio y no eliminar el signo + e insertar espacio (CTRL) en eqiv al tamaño original.