Estoy usando regularmente el parche y la diferencia de gnu-utils. El uso de git, hago a menudo:¿Hay una herramienta de diff (parche) que tenga en cuenta la sangría?
git diff
cambia a menudo simples crean un gran parche porque el único que cambió fue, por ejemplo, la adición de un if/else bucle y dentro de todo es una sangría a la derecha.
La revisión de dicho parche puede ser engorrosa porque solo la comparación manual línea a línea puede indicar si algo ha cambiado esencialmente dentro del código sangrado. Podemos estar hablando solo de unas pocas líneas de código, o de docenas (o mucho más) de código anidado. (Lo sé: una función tan hipotéticamente grande sería mejor dividirla en funciones más pequeñas, pero eso no viene al caso).
No se puede GNU diff/patch tener en cuenta cuando el único cambio dentro de un bloque de código es la sangría y que el desarrollador sepa tanto?
¿Hay otras herramientas de diferenciación que funcionen de esta manera?
Editar: Ok, hay --ignore-space-change pero entonces estamos en una cualquiera/o situación: o bien tenemos un parche humana, más legible o tenemos un parche completo que la máquina sabría cómo leer. ¿No podemos tener lo mejor de ambos mundos con una herramienta de diff más elaborada que mostraría los cambios en el espacio humano por lo que son, mientras que permite a la máquina aplicar el parche por completo?
+1 Es bueno saberlo. git diff -b> my.patch también funciona. Eso es útil. no funcionaría como un parche apropiado o de lo contrario no se aplicaría la sangría prevista. Me preguntaba si podríamos obtener lo mejor de ambos lados del problema, por ejemplo, tener un archivo de parche con 3 tipos de líneas (coloreado en consecuencia): líneas que no han cambiado, líneas que han cambiado (- o +) y las líneas que simplemente han sido sangradas ... Tanto la máquina sabría cómo aplicar el parche como el humano lo entendería mejor. – augustin