Importar historial de SVN a Git – Cambiar información del comitente

Estoy trabajando en la conversión de algunos repositorys de Subversion a Git usando la herramienta gitsvn. Noté que a pesar de que importa la información del autor correctamente, la información del autor no coincide con la información del autor (por ejemplo, la date del committer es la date / hora en que ejecuté la herramienta git-svn).

¿Hay alguna forma de que la información del autor coincida con la información del autor sobre la import de Subversion? Si no, ¿cómo puedo usar git-filter-branch para reescribir los commits para corregir esto (es decir, copyr la información del autor en la información del committer para cada commit)?

¡Gracias!

—ACTUALIZAR—

Git-svn no está causando este problema, ¡lo estoy! He estado modificando el historial de Subversion, y eso está cambiando la date del committer. Entonces, ¿alguien cómo usar git-filter-branch para cambiar esto (es decir, copyr la información del autor en la información del committer para cada commit)?

Está buscando el modo --env-filter de filter-branch. Las variables de entorno relevantes son GIT_AUTHOR_NAME , GIT_AUTHOR_EMAIL , GIT_AUTHOR_DATE , GIT_COMMITTER_NAME , GIT_COMMITTER_EMAIL y GIT_COMMITTER_DATE .

Tu command será algo así como:

 git filter-branch --env-filter ' export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" export GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"' -- --all 

El --all especifica que esto debería funcionar en todas las twigs. Sus references originales se conservarán en el espacio de nombres original / refs en caso de que se equivoque.

Y, por supuesto, no puedo publicar nada como esto sin una advertencia de los peligros para cualquiera que pueda suceder. Del hombre git-filter-branch:

¡ADVERTENCIA! El historial reescrito tendrá diferentes nombres de objects para todos los objects y no convergerá con la twig original. No podrá empujar y distribuir fácilmente la twig reescrita en la parte superior de la twig original. No utilice este command si no conoce todas las implicaciones, y evite usarlo de todos modos, si una simple confirmación simple fuera suficiente para solucionar su problema. (Consulte la sección "RECUPERACIÓN DE UPSTREAM REBASE" en git-rebase (1) para get más información sobre la reescritura del historial publicado).