git fusiona dos repositorys en uno nuevo, uno debe ser una twig

Quiero llevarlos a repositorys juntos, pero el segundo repository debe entrar en una twig

A - B - C - D - E - F - G - H Repo1 A1 - B1 - C1 Repo2 

Crete nuevo repo reponew

 git init reponew 

Agregue un control remoto y busque el viejo Repo Repo1

 git remote add -f Repo1 ..\..\output\Repo1 

Combina los files de Repo1 / master en new / master

 git merge Repo1/master --allow-unrelated-histories 

El nuevo repository reponew se ve así:

 A - B - C - D - E - F - G - H master 

Ahora he creado una nueva twig en commit y checkout específico

 git branch branchX 200303b0b215cc0fb2d92f50ffc9d7df8bbaab74 git checkout branchX 

Agregue un control remoto y busque el viejo Repo Repo1

 git remote add -f Repo2 ..\..\output\Repo2 

Combina los files de Repo1 / master en new / master

 git merge -Xtheirs Repo2/master --allow-unrelated-histories 

Y ahora el nuevo repository de repository se ve así:

  A1 - B1 - C1 branchX \ A - B - C - - - - - - - - - - - - - - \ D - E - - - - - F - G - H master 

Parece que esto es causado por la request de fusión que tiene una date de fusión de ahora

Pero me gustaría que se vea así:

 A - B - C - D - E - - - - - F - G - H master \ - - - A1 - B1 - C1 branchX 

La principal forma de "mover" se compromete DESPUÉS de que un historial existente sea usar rebase . Merge solo puede agregar un nuevo compromiso con ambos historiales como padres.
Pero rebase realmente no moverá al commista, sino que lo reproducirá después de lo especificado onto . Por lo tanto, si todavía hay una reference (twig o label) en las confirmaciones anteriores, permanecerán disponibles en todo el historial de confirmaciones.

En tu caso, quieres volver a establecer la base del historial de Repo2/master en la confirmación C

Entonces la solución es:

 git branch branchX --no-track Repo2/master git rebase -Xtheirs 200303b0b215cc0fb2d92f50ffc9d7df8bbaab74 branchX 

Deberías get el resultado que deseas.


Sugerido por @torek, también hay filter-branch . filter-branch te permite reescribir un historial de commit aplicando un filter en cada commit reescrito. Se utiliza principalmente para eliminar datos confidenciales erróneos (como la contraseña), eliminar files grandes del historial o cambiar la carpeta raíz de un repository. La ventaja de filter-branch es que también moverá las tags.
También filtrará confirmaciones con post vacío.

Con filter-branch , hay un --parent-filter que le permite cambiar el padre (s) de una confirmación durante el filtrado.
Filtrará todas las references enumeradas, de modo que para mover las tags, tenemos que enumerar todas las tags en la branchX actual: git tag --merged branchX , luego filtrarlas tal como están con --tag-name-filter cat .

Entonces el command será:

 git branch branchX --no-track Repo2/master git filter-branch \ --parent-filter 'test $GIT_COMMIT = <FULL-commit-id-of-A1> && echo "-p 200303b0b215cc0fb2d92f50ffc9d7df8bbaab74" || cat' \ --tag-name-filter cat \ -- branchX $(git tag --merged branchX) 

Luego tendrá el historial reescrito, pero aún el anterior disponible con references con el prefijo refs/original/ .

Si está bien, puede eliminar las references originales ( rm -rf .git/refs/original/ ); de lo contrario, puede restaurarlas ( cp -r .git/refs/original/refs .git && rm -rf .git/refs/original/ ).

Ok, cambié mi post de compromiso pnetworkingeterminado a vss2git, así que cada vez que use este post, lo cual es bueno por ahora.

Pero si selecciono mostrar todas las twigs, el repository se verá así:

  A1 - B1 - C1 Repo2 A - B - C - - - - - - - - - - - - - A1' - B1' - C1' branchX \ D - E - - - - - F - G - H master 

Y solo veo la label en C1, no se ha agregado ninguna label a C1 ', ¿alguna idea? Todas las otras tags están bien, como en CE o G.