git-subárbol sin squash: ver el registro

Question

He fusionado un árbol en un repositorio usando git subtree add sin la opción squash. Un registro de git muestra que los commits se agregaron con éxito al repositorio. Sin embargo, si hago un git log --follow filename, el historial se detiene en la fusión y no muestra las confirmaciones anteriores. Intenté usar -M en lugar de --follow y eso tampoco funciona. ¿Cómo puedo obtener un registro de las confirmaciones de un archivo o archivos específicos antes de la fusión?

Answer 1

realidad, git log --followdebe trabajo con subárbol se funde, pero es conocido por ser hacker durante mucho tiempo [13].

Uno puede quedarse con las combinaciones de subárboles y descansar asegurando que la estrategia es válida para rastrear historias múltiples, y esperar pacientemente el evento inevitable que git log --follow mejorará. Esto en realidad puede ser una decisión viable, ya que en la actualidad git log --follow puede ver algo de historia en casos muy útiles. Digamos que movió un archivo desde el repositorio de nivel superior a un sub-repo, luego puede rastrear el movimiento completo. Cuando desee rastrear el historial que es específico de un sub-repo, realmente debe tener una copia por separado o retirar una sucursal de sub-repo.

Alternativas y soluciones

Usted puede obtener los registros de los archivos de este tipo [1]:

git log -- '*filename'   # from the toplevel 

vistas cada confirmación de que tocó un archivo cuyo nombre termina con filename. No seguirá los cambios de nombre reales, y puede mostrar falso positivo si tiene varios archivos con el mismo nombre base [1].

También puede fusionar los repositorios utilizando diferentes estrategias. Ref. [4] muestra una forma de hacer esto que es muy similar a lo que tiene con la fusión de subárbol regular, pero con historiales rastreables. Básicamente, usted:

1. agregar, recuperar y fusionar cada sub-repositorio en el repositorio de niveles como un control remoto regular, sin subárbol ni árbol de lectura. Al principio, esto polucionará su directorio raíz como si fuera suyo, por lo que esto debe hacerse al comienzo de la vida de un proyecto.
2. git mv los archivos sub-repo a carpetas separadas

continuación:

• cambios aguas arriba puede ser exagerado y se fusionó con normalidad, pero con la bandera -Xsubtree a git merge.
• otros casos deben ser similares. He probado empujando hacia arriba y funciona, ver comentario en [4].

Referencias

[1] A partir de la lista de correo de git http://git.661346.n2.nabble.com/Bug-Files-are-losing-history-after-subtree-merge-td7597197.html

[2] A partir de la lista de correo de git http://git.661346.n2.nabble.com/gsoc-Better-git-log-follow-support-td6188083.html#a6188352

[3] git log --follow ha estado en el Google Summer of Code https://git.wiki.kernel.org/index.php/SoC2011Ideas#Better_git_log_--follow_support

[4] https://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history

Answer 2

La confirmación creada por git subtree merge o git subtree add hace un "agregar" para los archivos provenientes del subárbol, no como un "movimiento". Esto significa que su historial no puede ser rastreado como con otras fusiones o movimientos.

El historial del archivo que desea aún se puede mostrar al mirar directamente en el subárbol antes de la fusión. Si su espacio de trabajo es la combinación de fusión que se creó git subtree, el segundo elemento primario (HEAD^2) será la última confirmación del subárbol original. Desde aquí se puede ver el contenido del subárbol el original:

# Display the contents of the original subtree 
git ls-tree HEAD^2 

partir de este se puede cometer un seguimiento de los cambios en el archivo que está interesado. Tenga cuidado de que la ruta de su archivo sea diferente dentro del subárbol que en su área de trabajo. Tendrá que eliminar el --prefix dado a git subtree para tener la ruta correcta para su archivo.

git log HEAD^2 --follow -- path-in-subtree/file