He estado usando la extensión git-subtree https: //github.com/apenwarr/git-subtre) para gestionar subproyectos dentro de nuestro proyecto principal. Está haciendo exactamente lo que quiero, aparte del hecho de que falla cuando intento separar los cambios realizados en un subproyecto de nuestro proyecto principal.

p.ej. anteriormente había hecho

git subtree add -P Some/Sub/Dir --squash git@gitserver:lib.git master

para traer el código de la biblioteca a Some / Sub / Dir en nuestro proyecto principal. Todo aquí fue genial, así que luego envié mis cambios a nuestro proyecto central principal bare git repo. Luego decido hacer un cambio en mi versión local de la lib en Some / Sub / Dir, confirmarlo, luego dividirlo para enviarlo nuevamente al lib.git repo

git subtree split -P Some/Sub/Dir -b some_branch

todo funciona como se esperaba. Ya no necesito la copia local del repositorio, lo eliminé.

Después de clonar una nueva copia del repositorio de nuestro repositorio central, realicé algunos cambios en la biblioteca en Some / Sub / Dir y decidí que quería dividir esos cambios y devolverlos al repositorio lib.git. Intento usar el mismo comando de división de subárbol que antes, sin embargo, esta vez termino con el siguiente resultado:

1/      3 (0)
2/      3 (1)
3/      3 (1)
fatal: bad object d76a03f0ec7e20724bcfa253e6a03683211a7bb1

d76a03f0ec7e20724bcfa253e6a03683211a7bb1 proviene de cuando agregué el subárbol:

commit 43b3eb7d69d5eb64241eddb12e5bd74fd0215083
Author: Ian Bond <[email protected]>
Date:   Fri Apr 22 15:06:50 2011 -0400

    Squashed 'Subtree/librepoLib/' content from commit d76a03f

    git-subtree-dir: Subtree/librepoLib
    git-subtree-split: d76a03f0ec7e20724bcfa253e6a03683211a7bb1

que en realidad se refiere a una confirmación en el repositorio lib.git.

Lo que he podido reconstruir (y soy un novato git, así que puedo estar equivocado, pasar por alto algo o usar una terminología incorrecta aquí), es que 'git subtree add --squash' traerá toda la historia desde el repositorio lib.git remoto hasta el repositorio actual, aplánelo en una confirmación por separado, luego agregue esa confirmación en la rama de trabajo. El historial de confirmación de lib.git permanece en el repositorio actual, sin embargo, están pendientes de las confirmaciones, ya que en realidad no se hace referencia a ellas a través del texto de la confirmación de squash. Mientras esas confirmaciones pendientes permanezcan, git-subtree puede usarlas para realizar divisiones, sin embargo, dado que un empuje o extracción no contiene objetos colgantes (o si ejecuto un gc y podo completamente los objetos colgantes), esas confirmaciones colgantes se pierden y git-subtree ya no tiene la información necesaria para realizar la división.

He añadidoun guió que reproducirá completamente los problemas que he tenido.

Mis preguntas son:

1) ¿Qué puedo hacer para manejar la situación existente en la que ahora tengo subárboles que deseo fusionar con su repositorio de origen, pero ya no tengo ningún tipo de historial que los vincule? Mi pensamiento actual es hacer algo como:

git subtree split -P Some/Sub/Dir 43b3eb7^.. --ignore-joins -b splitBranch

para dividir todo el historial desde el 'git subtree add' y fusionarlo nuevamente en el repositorio de origen (que afortunadamente no ha tenido ningún cambio desde el add). ¿Es este el mejor camino a seguir? ¿Alguna recomendación sobre cómo debo realizar la fusión?

2) ¿Hay algo que pueda hacer para que git-subtree funcione como se espera? Creo que si omito el parámetro --squash en 'git subtree add', todo funcionará, sin embargo, eso causa que se inyecte un montón de historial no relacionado en mi repositorio. ¿Hay alguna forma de mantener las confirmaciones necesarias (preferiblemente sin mantener todo el historial de la biblioteca)?