Uso de git filter-branch para reescribir autores/committers y mensajes de confirmación simultáneamente

Question

Tengo un repositorio de Git importado originalmente de Subversion. Las partes de la información del autor/compilador son incorrectas, lo que no es culpa de Git, sino que se debe principalmente al compromiso descuidado con Subversion.

Me gustaría usar git filter-branch para reescribir el historial del repositorio, corrigiendo la información del autor y del autor.

El problema es ... Tengo que sorber información del autor de los mensajes de confirmación . Por lo que puedo decir, git filter-branch le permite filtrar y alterar la información del autor (con --env-filter) y/o filtrar los mensajes de confirmación (con --msg-filter), pero no para hacer ambas cosas simultáneamente, con información compartida entre los diferentes filtros .

Así que estoy algo perplejo acerca de cómo hacer esto ... lo mejor que puedo pensar es hacerlo en varias pasadas: primero, recopilar todos los mensajes de confirmación, luego hacer una secuencia de comandos para filtrar y filtrar toda la información del autor/committer. Esto parece bastante poco elegante y propenso a errores, así que me pregunto si alguien más ha descubierto que hace este tipo de trabajo de manera más fluida.

Answer 1

Lo único que se me ocurre para hacerlo en una pasada es utilizar un filtro de confirmación. Al igual que el filtro de mensajes, lleva el mensaje de registro en stdin, por lo que podrá analizarlo y descubrir lo que necesita. A continuación, puede establecer las variables adecuadas usted mismo y llamar al git commit-tree usted mismo. (El filtro de comprometerse es esencialmente una gota en el reemplazo para cometer-árbol, teniendo los mismos argumentos y producir la misma salida.)

En bash, sería algo como esto:

message=$(read_from_stdin) 

modify_env_vars "$message" 

echo "$message" | git commit-tree "$@" 

I Nunca he intentado esto, pero no veo por qué no funcionaría, ¡suponiendo que escribas esas dos funciones de shell correctamente!

(Y solo una pequeña nota: no es tanto que --env-filter y --msg-filter no se puedan influenciar entre sí, sino que siempre se ejecutan en ese orden. Por lo tanto, el primer filtro podría dejar efectos secundarios en los archivos o entorno para que el otro lo vea, pero están en un orden que evita que haga lo que desea).