git - tipos - Agregar solo los cambios que no sean espacios en blanco

¿para qué nos sirve el sha-1 cuando creamos tags?

Question

Tengo mi editor de texto para recortar automáticamente los espacios en blanco finales al guardar un archivo, y estoy contribuyendo a un proyecto de código abierto que tiene graves problemas con los espacios en blanco finales.

Cada vez que trato de enviar un parche, primero debo ignorar manualmente todos los cambios de solo espacios en blanco, para elegir solo la información relevante. No solo eso, sino que cuando ejecuto git rebase lo general me encuentro con varios problemas debido a ellos.

Como tal, me gustaría poder agregar al índice solo los cambios que no sean espacios en blanco, de una manera similar a la que hace git add -p , pero sin tener que elegir todos los cambios.

¿Alguien sabe como hacer esto?

EDITAR: No puedo cambiar la forma en que funciona el proyecto y, después de analizarlo en la lista de correo, decidieron ignorarlo.

Answer 1

¿Qué hay de lo siguiente:

git add `git diff -w --ignore-submodules |grep "^[+][+][+]" |cut -c7-`

El comando dentro de backquotes obtiene los nombres de los archivos que tienen cambios que no son espacios en blanco.

Answer 2

Agregue lo siguiente a su .gitconfig :

anw = !git diff -U0 -w --no-color -- /"$@/" | git apply --cached --ignore-whitespace --unidiff-zero "#"

Gracias a la respuesta de @Colin Herbert por la inspiración.

Sintaxis explicacion

El # final debe citarse para que no se trate como un comentario dentro de .gitconfig , sino que se pase y se trate como un comentario dentro del shell. Se inserta entre el final de la git apply y los argumentos proporcionados por el usuario. que git coloca automáticamente al final de la línea de comando. Estos argumentos no son necesarios aquí, no queremos que git apply para consumirlos, de ahí el carácter de comentario anterior. Es posible que desee ejecutar este comando como GIT_TRACE=1 git anw para ver esto en acción.

El -- señala el final de los argumentos y permite el caso de que tenga un archivo llamado -w o algo que parezca un cambio a git diff .

Se requieren comillas dobles escapadas alrededor de $@ para preservar cualquier argumento entregado por el usuario. Si el " carácter no se escapa, será consumido por el analizador .gitconfig y no llegará al shell.

Nota: el análisis de alias .gitconfig no reconoce las comillas simples como algo especial, sus únicos caracteres especiales son " , / , /n , y ; (fuera de una " cadena entre comillas). Esta es la razón por la que siempre se debe escapar un " , incluso si parece que está dentro de una cadena entre comillas simples (sobre la cual git es completamente agnóstico).

Esto es importante, por ejemplo. si tiene un alias práctico para ejecutar un comando de bash en la raíz del árbol de trabajo. La formulación incorrecta es:

sh = !bash -c ''"$@"'' -

Mientras que el correcto es:

sh = !bash -c ''/"$@/"'' -

Answer 3

Cree un archivo de parche que contenga solo los cambios reales (excluyendo las líneas con solo los cambios de espacio en blanco), luego limpie su área de trabajo y aplique ese archivo de parche:

git diff> copia de seguridad
git diff -w> cambios
git reset - hard
parche <cambios

Revise las diferencias restantes, luego add y commit normalmente.

El equivalente para Mercurial es hacer esto:

hg diff> backup
hg diff -w> cambios
hg revertir --todos
hg import --no-commit cambios

Answer 4

Encontré un gancho de pre-confirmación de git que elimina los espacios en blanco finales . Sin embargo, si no puede hacer que otros usen esto, entonces puede que no sea una solución válida.

  #!/bin/sh

  if git-rev-parse --verify HEAD >/dev/null 2>&1 ; then
     against=HEAD
  else
     # Initial commit: diff against an empty tree object
     against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
  fi
  # Find files with trailing whitespace
  for FILE in `exec git diff-index --check --cached $against -- | sed ''/^[+-]/d'' | sed -r ''s/:[0-9]+:.*//'' | uniq` ; do
     # Fix them!
     sed -i ''s/[[:space:]]*$//'' "$FILE"
  done
  exit

Answer 5

Esto funciona para mí:

Si quieres mantener un alijo alrededor, esto funciona

git stash && git stash apply && git diff -w > foo.patch && git checkout . && git apply foo.patch && rm foo.patch

No me gustan los escondites, pero me he topado con un error en git + cygwin en el que perdí los cambios, así que para asegurarme de que las cosas fueran al reflog al menos configuré lo siguiente:

git add . && git commit -am ''tmp'' && git reset HEAD^ && git diff -w > foo.patch && git checkout . && git apply foo.patch && rm foo.patch

Básicamente, creamos un diff que no incluye los cambios de espacio, revertimos todos nuestros cambios y luego aplicamos el diff.

Answer 6

La respuesta más votada no funciona en todos los casos, debido a los espacios en blanco en el contexto del parche de acuerdo con los usuarios en los comentarios.

Revisé el comando de la siguiente manera:

$ git diff -U0 -w --no-color | git apply --cached --ignore-whitespace --unidiff-zero

Esto genera un parche sin contexto. No debería ser un problema ya que el parche es de corta duración.

Alias ​​correspondiente, nuevamente una revisión de lo que ya fue proporcionado por otros usuarios:

addw = !sh -c ''git diff -U0 -w --no-color "$@" | git apply --cached --ignore-whitespace --unidiff-zero'' -

Answer 7

La solución @Frew no era exactamente lo que necesitaba, por lo que este es el alias que hice para el mismo problema:

alias.addnw=!sh -c ''git diff -U0 -w --no-color "$@" | git apply --cached --ignore-whitespace --unidiff-zero -''

O simplemente puede ejecutar:

git diff -U0 -w --no-color | git apply --cached --ignore-whitespace --unidiff-zero -

Actualizar

De acuerdo con este comentario , se -U0 opciones -U0 , y --unidiff-zero respectivamente, a la solución de problemas de coincidencia de contexto.

Básicamente, aplica el parche que se aplicaría con add sin cambios de espacios en blanco. Notarás que después de git addnw your/file un git addnw your/file todavía habrá cambios sin etapas, quedan los espacios en blanco.

El --no-color no es requerido pero como tengo colores establecidos para siempre, tengo que usarlo. De todos modos, es mejor prevenir que lamentar.

Answer 8

Primero debe considerar si el espacio en blanco al final es intencional. Muchos proyectos, incluidos el kernel de Linux, Mozilla, Drupal y Kerberos (para nombrar algunos de la página de Wikipedia sobre estilo) prohíben los espacios en blanco finales. De la documentación del kernel de Linux:

Obtenga un editor decente y no deje espacios en blanco al final de las líneas.

En su caso, el problema es al revés: las confirmaciones anteriores (y quizás las actuales) no siguieron esta guía.

Apostaría a que nadie quiere realmente los espacios en blanco al final, y solucionar el problema podría ser un cambio bienvenido. Otros usuarios también pueden estar experimentando el mismo problema que tú. También es probable que los contribuyentes que están agregando espacios en blanco al final no sepan que lo están haciendo.

En lugar de intentar reconfigurar git para ignorar el problema, o deshabilitar la funcionalidad deseable en su editor, comencé con una publicación en la lista de correo del proyecto que explica el problema. Muchos editores (y git en sí) pueden configurarse para tratar con espacios en blanco finales.