Git cambio de nombre de file. El historial está disponible en cmd-line, pero no en la interfaz de github?

Ha habido muchas publicaciones excelentes sobre cómo preservar la historia al cambiar el nombre de files y carpetas en Git.


Esto funciona en la interfaz de command-line de git:

#if you don't modify oldname.cpp or newname.cpp, git will understand your rename git mv old.cpp new.cpp git commit -am "renamed old.cpp -> new.cpp" git log new.cpp #only shows the new commit git log --follow new.cpp #shows ALL the history of old.cpp and new.cpp 

Genial, entonces el command --follow nos permite get toda la historia de new.cpp después de que ha sido renombrado. Esto funciona muy bien en la interfaz de command-line para git.


Pero, en la interfaz web de github, el historial de old.cpp no aparece para new.cpp . Esto es un problema, porque muchos de los miembros de mi equipo ven sus counts de github como parte de sus curriculums vitae. Si sus confirmaciones no se muestran en github después de cambiar el nombre de los files, están perdiendo puntos de reanudación. Después de una importante reestructuración de nombre de file / directory, un queueborador puede terminar sin tener una única confirmación visible en un repository.

¿Cómo puedo get el historial completo del file para que aparezca en la interfaz web de github (por ejemplo, git log --follow ) después de cambiar el nombre de los files?

¿O estoy atascado sin cambiar nunca el nombre de nada, a less que esté dispuesto a que los usuarios ocasionales de Github nunca vean los viejos commits?

Como probablemente sepa de esas tres preguntas que ha vinculado, no hay nada en Git que rastree un movimiento de file. Para Git, solo se elimina un file y se agrega otro file. Solo la interfaz hace un reconocimiento de los movimientos de files en function de la similitud de los contenidos. Por lo tanto, si GitHub no proporciona el seguimiento de los cambios en un file que podría haberse movido antes, no hay mucho que pueda hacer al respecto aparte de pedirle a GitHub que trabaje en eso.

Dicho esto, su afirmación de que un movimiento de file hará que un contribuyente termine sin confirmaciones visibles es falsa. Sí, si miro el historial de un solo file que se eliminó antes, podría parecerlo, pero, como es posible ahora, Git no olvida algo que sucedió en el repository. Y el logging para el repository aún contendrá cada compromiso que sea visible desde una twig determinada. Y eso obviamente también incluye compromisos que ocurrieron antes de que se movieran los files (porque Git rastrea el contenido, no los cambios). Por lo general, puede get el logging de commit en https://github.com/<user>/<project>/commits/<branch> .

Y aquí viene otro punto: el logging incluye solo aquellas confirmaciones, que son visibles desde la twig dada. Entonces, si trabajas en varias sucursales, de todos modos, todo esto es bastante estúpido. Si desea tener una idea de cuánto contribuye un queueborador en un proyecto, debe usar los charts del proyecto en https://github.com/<user>/<project>/graphs/contributors .

Pero, por supuesto, medir el conteo de compromisos no es una buena métrica de todos modos (lo mismo con cosas como la razón LOC ).