git - submodule - Fusionar cambios de subárbol-fatal: ruta no válida ''somefile_BASE_20704.cs''

git subtree push

Question

Tengo tres reposiciones - nombres cambiados por claridad:

SharedStuff , ProjectA y ProjectB

Ambos proyectos utilizan git-subárbol para mantener una copia local de SharedStuff . Ambos han hecho cambios locales que estoy intentando fusionar centralmente, probar y luego volver a fusionar con cada uno.

He ejecutado esto en el repositorio de ProjectA:

git subtree split --prefix=SharedStuff -b SharedStuff_from_ProjectA --rejoin

... luego lo SharedStuff repositorio de SharedStuff , resolvió algunos conflictos simples y lo fusionó.

Ahora he ejecutado esto en el repositorio de ProjectB:

git subtree split --prefix=platform/SharedStuff -b SharedStuff_from_Project_B --rejoin

... y otra vez empujó eso al repo de SharedStuff en una nueva rama. El problema ocurre cuando intento fusionar esos cambios en.

En el caso actual, cambio a la rama SharedStuff_from_Project_B , luego git merge master , pero de inmediato aparece todos los archivos modificados como conflictos de agregar / agregar . Cuando ejecuto git mergetool , cada uno tiene un error como este:

Merging:
somefile.xyz

Normal merge conflict for ''somefile.xyz'':
  {local}: created file
  {remote}: created file
fatal: invalid path ''./somefile.xyz_BASE_20704.cs''

(Por supuesto, si intento lo contrario, para fusionar SharedStuff_from_Project_B en master , obtengo los mismos tipos de conflictos, solo se invierte. Todavía agregue / agregue).

Mi conjetura es que algo podría estar mal en la historia de ProjectB, causando la aparición de agregar / agregar. Sin embargo, no estoy seguro de cómo diagnosticar esto aún más. ¿Qué puedo hacer?

Edición : hubo un subárbol anterior "reincorporarse" a la confirmación en ProjectB , pero los cambios no se fusionaron en SharedStuff en ese momento, según parece. Sin embargo, volver a ejecutar git subtree split con --ignore-joins produce el mismo problema: muchos conflictos de combinación add/add , a pesar de que el historial de esa rama de subárbol dividido se remonta a cuando SharedStuff se colocó por primera vez en ProjectB . :(

Edición : también git merge-base entre el subárbol dividido de ProjectB y master en SharedStuff no da ningún resultado. ¿No estoy seguro de cómo llegó a ser esto o cómo resolverlo?

Answer 1

No sé qué causó esto. Sin embargo, así es como lo resolví, algo así. ¡Todavía quiero mejores respuestas!

Ambos ''compartidos'' SharedStuff el maestro real en SharedStuff y la copia separada de ProjectB tenían los mismos compromisos en su historial lejano; bueno, los mismos cambios con SHA en el mismo tree internamente, pero diferentes SHA para compromisos. Esto se debe a que, de alguna manera, la rama ProjectB tuvo un primer compromiso inicial diferente al de SharedStuff .

Mientras no haya confirmaciones comunes (con los mismos SHA) en la historia, la fusión, la reorganización, etc. no podrá encontrar un terreno común y supondrá que los archivos se agregaron en ambas historias.

La solución: encuentre dos confirmaciones tempranas en el historial con el mismo tree SHA (es decir, exactamente el mismo contenido de archivo), e información de confirmación (mensaje, autor, etc.) y "sobrescriba" manualmente el padre de esa confirmación en la rama dividida de ProjectB para El padre en el maestro de SharedStuff .

Hice esto usando un injerto: Establecer el puntero padre git a un padre diferente

1. Escriba una nueva línea para .git/info/grafts , básicamente wrong-parent right-parent
2. Cambie a la rama: descubra que PowerShell echo utiliza un formato de caracteres de 16 bits, vuelva a guardar con Sublime Text y vuelva a cambiar;)
3. Ejecute git filter-branch right-parent..HEAD en la rama para sellar el trato
4. Verifica que todo sea fusionable.

El próximo desafío divertido será ver cómo esta versión se fusiona nuevamente con ProjectB ; se actualizará cuando haya terminado ..

Aún así, realmente agradecería una respuesta real a esto, ¡esto es realmente intrépido!