Trayendo dos repositorys git diferentes juntos sin perder ningún historial

En mi proyecto actual, estoy enfrentando un problema interesante con git:

Desde el comienzo del proyecto, los cambios se almacenaron en un repository SVN en un server remoto en mi cliente. En el progreso del desarrollo comencé a tener un repository git local en paralelo para que me fuera más fácil probar nuevas características sin romper la versión actual. Lamentablemente, git-svn no funcionó, lo que me habría facilitado la vida.

Ahora mi cliente cambia a otro server y en este process movieron el repository SVN a git (usando git2svn).

Aunque estoy contento con esto en general, ahora tengo dos problemas :

  1. Como trabajé en una function más grande, no me comprometí con SVN durante 7 días. Trabajé en una twig local de características y realicé copys de security de eso en mi server local, pero la copy SVN que ahora es el repository git remoto está desactualizada en comparación con mi versión local.

  2. Dado que el repository remoto ha sido creado por git2svn, es totalmente diferente de mi propio repository (post: Advertencia: Repo no tiene confirmaciones comunes), lo que hace que la fusión estándar sea imposible.

Ahora mis objectives deseados :

  1. Combine ambos repositorys para que mi versión actual sea la marcada y vuelva a funcionar.

  2. Mantenga el historial de ambos repos (antiguos de SVN así como los de los últimos 7 días de mi git)

Lo que intenté hasta ahora :

Traté de clonar el git remoto (de svn) y fusioné mi repository local en él. Tengo 153 conflictos con "cambiado en ambas versiones". La aceptación de "ellos" (es decir, mis últimos desarrollos) pierde la historia del file (simplemente comienza con la initialization con mi repository paralelo de git).

Mi idea es que puedo crear un parche para cada confirmación de los últimos 7 días y comprometerlo con el nuevo repository con el post de confirmación correspondiente (es decir, "fusión manual"). Antes de escribir un script para hacer esto, quería preguntar si hay una forma integrada de hacerlo.

¡Gracias por adelantado!

ACTUALIZACIÓN : Intenté muchas soluciones, pero todas me fallaron. El problema básico es que ahora tengo dos twigs sin una confirmación común única, pero con la misma estructura de tree . Esto da como resultado conflictos de combinación como "agregado en ambas twigs" porque git no sabe que myFile.txt" and myFile.txt" son los mismos y se pueden fusionar. En cambio, tengo que hacer una fusión manual de los 150 files que modifiqué en esa semana, lo que no puedo ni quiero hacer.

Mi mejor enfoque hasta ahora fue crear un parche para los cambios y aplicarlo al "nuevo" repository. Pero no pude crear un parche que no fallará aún debido a una incompatibilidad de treees. Todavía tengo que encontrar el compromiso correcto para comenzar la información del parche.

Resolución

TL; DR: No hay ninguno. Usted puede simplemente elegir entre el mal menor.

  1. Puede usar el método de fusión descrito aquí pero replaceá el historial de files individuales del SVN con el de su git lateral (es decir, no puede search por qué este file ha sido cambiado hace 3 meses si su otro repository es solo 2 Meses de edad). Pero, en el lado positivo, todavía tienes tus cambios fusionados en la historia global a través de git log.

  2. La otra opción que terminé fue copyr y replace todos los files en el repository "nuevo" (también conocido como SVN) con el estado actual de mi repository git (a través de cp -vru pero omitiendo la carpeta .git y todos los files generados) . Esto me permite perder la historia de una semana, pero todavía me permite mirar hacia atrás hasta el comienzo del proyecto que prefiero. Para aliviar el dolor de esta pérdida un poco hice un resumen detallado de mis acciones en el post de confirmación usando git log --date=short --pretty="format:%cd - %s" --name-status que al less me da la oportunidad de volver a esta input y ver un post con una descripción. Pero, por supuesto, esto no funcionará para las eliminaciones de files y no puede saber qué cambio pertenece realmente a qué parte del post de confirmación de biiiig.

Acabo de probar esto con un repository mío. Creé un nuevo clon que representa el nuevo repository de su cliente. Luego copié el contenido de una versión anterior en una nueva carpeta y lo inicialicé en un repository. Agregué los contenidos e hice algunos commits.

De esa forma tuve dos repositorys sin compromiso común.

Ahora, en el nuevo repository, agregué mi copy (en lo siguiente: la mine ) como un control remoto y busqué su contenido. Luego revisé una nueva twig para el maestro de la mina:

 git checkout -b new mine/master 

Así que tuve todo el historial de mi repository separado accesible desde esta twig. Luego fusioné el maestro actualizado en mi sucursal, utilizando una estrategia de fusión recursiva pero a favor de nuestros (nuevos) cambios para conflictos:

 git merge master -s recursive -Xours 

Esto fusionará automáticamente todo y, en caso de conflictos, los resolverá automáticamente con solo usar nuestras versiones, descartando los cambios en el maestro.

Por lo tanto, debe terminar con una twig fusionada y todo el historial de ambos repositorys todavía está allí.

Si entiendo correctamente, tienes una situación como esta:

 remote repo: A - B your repo C - D - E - F 

Donde commit A es realmente idéntico a C, y cometer B a D (con respecto a los files contenidos). Creo que lo que podría funcionar es simplemente volver a basar tu trabajo en los últimos commit remotos, haciendo algo como

 git rebase --onto BD 

Esto debería llevar sus confirmaciones de D a su CABEZA (por ejemplo, F) y aplicarlas como parches a B, lo que da como resultado:

 A - B - E' - F' 

Esto entonces debería ser idéntico a los cambios locales, y podría llevarse cómodamente al repository remoto.