git: cambiar el estilo (espacios en blanco) sin cambiar la propiedad/culpa?

Tenemos una base de código masiva y antigua que necesita mucha limpieza. Siempre hemos tenido estándares de codificación y todos siempre han intentado seguirlos, pero no se aplicaron, por lo que con el tiempo se han introducido muchas violaciones. Muchos de ellos son solo problemas de espacio en blanco, como el uso de pestañas en lugar de espacios o espacios donde hay no debería ser ninguno, o espacios faltantes donde deberían estar. Vamos a empezar a aplicar activamente nuestros estándares de codificación para asegurarnos de que no se presenten más infracciones, pero es difícil aplicarlos de manera automatizada solo en los cambios, por lo que sería bueno limpiar estos archivos antiguos.git: cambiar el estilo (espacios en blanco) sin cambiar la propiedad/culpa?

Existen herramientas que pueden automatizar la solución de estos problemas, sin embargo, si hago eso, entonces la culpa me mostrará como el propietario de esas líneas, cuando en realidad quizás nunca las haya visto. Sé que hay un entorno para hacer que la culpa ignore los cambios en el espacio en blanco, pero no puedo hacer que todos usen la culpa de la misma manera, incluidas otras herramientas visuales y cosas como gitstats. En un mundo ideal, habría alguna forma de reescribir la historia para que pareciera que nunca se introdujeron las violaciones, sin encubrir quién introdujo el código real, pero no puedo encontrar nada de eso.

Fuente

2010-11-06 Jay Paroline

El historial de reescritura es un poco incómodo: una vez que cambie las confirmaciones, otras tendrán que recoger esos cambios. No es parte de un flujo de trabajo ideal. Es posible que desee estudiar la aplicación de sus estándares de codificación mediante el uso de ganchos.Puedes usar un gancho de actualización para hacer la ejecución final cuando presionas a un repositorio central, y puedes darles a los desarrolladores un gancho precompromiso para hacer la misma validación para ellos, e incluso arreglarlo automáticamente si es seguro hacerlo. (Si quiere arreglar lo que ya está allí, lo haría en una única confirmación, sin necesidad de pasar por el dolor de cabeza de reescribir todo el historial.) – Cascabel

posible duplicación de [Git commit que no anula a los autores originales en git culpa] (http://stackoverflow.com/questions/3945382/git-commit-that-doesnt-override-original-authors-in-git-blame) –

No creo que esto sea exactamente un duplicado de esa pregunta . En mi pregunta, expresé específicamente que cambiar los indicadores de culpa no es adecuado, y la respuesta aceptada a esa pregunta es exactamente eso. –

En un mundo ideal no habría alguna manera de reescribir la historia para parecerse a las violaciónes no se introdujeron

git filter-branch hace precisamente eso.

http://git-scm.com/docs/git-filter-branch

Esto tiene los mismos problemas que todo el historial de comandos de reescritura hacen, ya que en esencia invalida todos los repositorios clonados.

Fuente

2010-11-06 08:17:31 wnoise

¡Gracias, investigando esto ahora! –

¡Lo tengo funcionando! 'git filter-branch --tree-filter 'git diff-tree --name-only --diff-filter = AM -r --no-commit-id $ GIT_COMMIT | php cleanup.php 'HEAD' –

¿Cómo es tu cleanup.php? – Cybot

Si está intentando obtener un problema de causa raíz utilizando la culpa, no olvide utilizar el indicador -w para ignorar todos los espacios en blanco o cambios de sangría. De modo que obtendrá el último cambio real en el código, en lugar de solo una sangría, o eliminará los espacios finales.

git blame -w app/to/file.rb

o simplemente puede usar, comando git bofetada ..

git config alias.slap "blame -w"; 
git slap app/path/to/file.rb

tener los mismos resultados: D

Fuente

2010-11-22 19:47:45

¿De dónde viene este comando 'git slap'? –

@ErikAllik No estoy seguro de lo que quiere decir, pero una línea antes de que se use 'git slap', se define como un alias para' git blame -w'. – blinry

Una de las desventajas del argumento de espacio en blanco de -w es que tiene en cuenta la refactorización del orden de los métodos, la eliminación de comentarios sueltos y muchas cosas más. – JosephMCasey

hice una solicitud de extracción a la TextMate git Bundle, para establecer este "w" parámetro de forma predeterminada para el comando "Buscar archivo anotado (Blame)". Gracias Mario Zaizar, hiciste mi día.

diff --git a/Support/lib/git.rb b/Support/lib/git.rb 
index 5e8de13..5192953 100644 
--- a/Support/lib/git.rb 
+++ b/Support/lib/git.rb 
@@ -307,6 +307,9 @@ module SCM 
     file = make_local_path(file_path) 
     args = [file] 
     args << revision unless revision.nil? || revision.empty? 
+  # Ignore whitespace when comparing the parent's version and 
+  # the child's to find where the lines came from. 
+  args << '-w' 
     output = command("annotate", *args) 
     if output.match(/^fatal:/) 
     puts output

Fuente

2010-12-17 13:01:31 nfo

Basándose en Mario's answer, sugeriría git shame como git-Alias global:

git config --global alias.shame 'blame -w -M'

... y usarlo en lugar de git-culpa:

git shame path/to/file

Para explicar :
- -w Ignora los cambios en el espacio en blanco, para no culpar a alguien que volvió a sangrar el código
- -M Detecta líneas que se movieron o copiaron, y culpa al autor original

Fuente

2017-06-29 14:03:09 Gonen

git: cambiar el estilo (espacios en blanco) sin cambiar la propiedad/culpa?

Respuesta

Cuestiones relacionadas