traemos - tipos de etiquetas en git

Cómo manejar cambios de formato de código generalizados en un repositorio git (4)

Tenemos un proyecto con alrededor de 500,000 líneas de código, administradas con git, muchas de ellas con varios años de antigüedad. Estamos a punto de realizar una serie de modificaciones para poner el código anterior en conformidad con los estándares y las mejores prácticas actuales de la comunidad de desarrolladores, con respecto a las convenciones de nomenclatura, el manejo de excepciones, la sangría, etc.

Se puede considerar como algo entre impresión bonita y refactorización mecánica / de bajo nivel.

Es probable que este proceso toque casi todas las líneas de código en la base del código (~ 85%), y algunas líneas estarán sujetas a un máximo de cinco modificaciones. Todos los cambios pretenden ser semánticamente neutros.

¿Hay alguna forma de hacer que los cambios sean transparentes a la culpa de Git, etc. de modo que al mirar el código dentro de un mes veremos que se introdujo la lógica, no en la que se cambió la sangría o el uso de mayúsculas?

¿Cuál es la mejor manera de extraer las combinaciones de las horquillas que no han sufrido este proceso? Mi plan actual sería hacer que un script clonara el repositorio bifurcado, aplicara el proceso automatizado a él y su base, los diferencie, luego aplique el dif. Pero me encantaría tener una respuesta más limpia.

¿Hay algún otro problema de este tipo que no esté viendo y, de ser así, qué se puede hacer para mitigarlos? Estoy pensando que git bisect, etc. debería estar bien, git log, etc. cruzar la gran división será molesto a menos que tenga cuidado, y git diff no tendrá remedio, pero no estoy convencido de que no esté pasando por alto a otro Punto de dolor.

Esta question tiene una buena solución para ello. Brevemente use git filter-branch .

Utilicé para mí este código:

git filter-branch --tree-filter "git diff-tree --name-only --diff-filter=AM -r --no-commit-id /$GIT_COMMIT | grep ''.*cpp/|.*h'' | xargs ./emacs-script" HEAD

Qué ./emacs-script es un script que escribí usando emacs para cambiar el estilo del código, simplemente llama a indent-region en cada archivo.

Este código funciona bien si no hay ningún archivo que se haya eliminado o eliminado del repositorio. En esa situación, usar --ignore-unmatch puede ser útil, pero no estoy seguro.

No sé cuál es la mejor manera de lidiar con algunos de los cambios más invasivos que está describiendo, pero ...

La opción -w para git blame , git diff , y otras hace que git ignore los cambios en el espacio en blanco, para que pueda ver más fácilmente las diferencias reales.

Recomendaría hacer esas evoluciones paso a paso, en un repositorio central de Git (central como en "referencia pública para que sigan todos los demás repositorios):

sangría
luego reordenar métodos
luego renombrando
entonces ...

Pero no es "un sangrado-reordenar-renombrar -...- un gigante cometer".

De esa manera, le da a Git una oportunidad razonable de seguir los cambios a través de las modificaciones de refactorización.

Además, no aceptaría ninguna combinación nueva (extraída de otro repositorio) que no haya aplicado la misma refactorización antes de presionar su código.
Si aplicar el proceso de formato trae algún cambio al código recuperado, puede rechazarlo y solicitar que el repositorio remoto se ajuste primero a los nuevos estándares (al menos tirando de su repositorio antes de seguir presionando).

También necesitará un mergetool que permita ignorar agresivamente los espacios en blanco. p4merge hace esto, y se puede descargar libremente.