Pregunta sobre git, github, git-filter-branch – "Git filter-branch" se utilizó con éxito para cambiar el autor / autor, pero los cambios no se reflejan en github

6

Recientemente reemplacé al autor, al remitente y a los correos electrónicos de los mismos en todos mis confirmaciones locales, usando el siguiente comando:

git filter-branch -f --env-filter '
if [ "$GIT_COMMITTER_NAME" = "oldname" ];
then
    GIT_COMMITTER_NAME="newname";
    GIT_COMMITTER_EMAIL="newaddr";
    GIT_AUTHOR_NAME="newname";
    GIT_AUTHOR_EMAIL="newaddr";
fi

if [ "$GIT_AUTHOR_NAME" = "oldname" ];
then
    GIT_COMMITTER_NAME="newname";
    GIT_COMMITTER_EMAIL="newaddr";
    GIT_AUTHOR_NAME="newname";
    GIT_AUTHOR_EMAIL="newaddr";
fi
' -- --all

Las actualizaciones son inmediatamente evidentes a nivel local (por ejemplo, en mi entorno de SourceTree). Sin embargo, después de forzar el repositorio modificado a GitHub ...

git push -f origin master

… Dos elementos individuales se niegan obstinadamente a que se actualice a su autor y autor: el archivo Gemfile.lock y un directorio de Vistas.

Tenga en cuenta también que:

Esta es la segunda vez que estoy realizando este tipo de operación en este repositorio. Creo que no tuve que enfrentar tales problemas la primera vez.

Buscando mi antiguo nombre en el repositorio ...

$ find . "<oldname">

… hace produce un montón de resultados, lo que significa que el nombre antiguo aún se esconde en muchos de los archivos del repositorio, incluidos los archivos que aparecen actualizados tanto en GitHub como localmente.

Mi pregunta, entonces: ¿Cómo puedo cambiar el autor / autor de los dos archivos "rebeldes" en GitHub?

¿Qué quiere decir cuando dice que Gemfile.lock y Views "se niegan a tener a su autor y autor actualizados"? Solo los comités tienen comitente y autor, no árboles y manchas. Además, la rama de filtro que ejecutó no haría nada con respecto a los archivos con el nombre "nombre antiguo". Además, podría ser útil publicar la URL de github. Max Nanasy
Tal vez GitHub está almacenando esta información en caché? ¿Presionar el repositorio a una nueva rama o un nuevo repositorio causa el mismo problema? Vladimir Panteleev

Tu respuesta

2   la respuesta
5

git aún conserva una copia de respaldo del historial del repositorio en refs / original. Esto es para que si se ensucia algo con la rama de filtro, puede revertir si es necesario. Una vez que esté seguro de que todo salió bien, puede eliminar la referencia respaldada con:

git update-ref -d refs/original/refs/heads/master

Por alguna razón, todavía se necesita una confirmación adicional para que github refleje el cambio. Agregaré un espacio o algo al archivo Léame, cometer y presionar ... después de eso, github refleja los autores correctos en la página del proyecto.

0

e la línea? Es probable que esté almacenado en caché, o que esté viendo algo específico del antiguo compromiso SHA1.

Puede probar que funcionó haciendo un nuevo clon del repositorio y comprobandogit blame filename para esos dos archivos. Si eso muestra al autor correcto, entonces funcionó.

Preguntas relacionadas