git-svn: compromete todo el historial de un repository de git existente en un subdirectory de Subversion vacío

He estado trabajando en algún código localmente en mi computadora, rastreando modificaciones usando git (sin control remoto). Ese código ahora se convertirá en un module en un proyecto más grande, cuyo código base está almacenado en Subversion (algo así como https://svnserver/svnroot/project/trunk/module_x ), así que pensé que podría usar git-svn para administrar el repository de Subversion como un control remoto. Recuerdo haberlo hecho antes para otro proyecto, pero no pude encontrar el modus operandi (cambié las computadoras en el medio).

Esto es lo que intenté:

 cd ~/mygitrepo/ git svn init https://svnserver/svnroot/project/trunk/module_x git svn fetch git svn rebase 

El último command produce el siguiente post de error:

 Unable to determine upstream SVN information from working tree history 

Leí en alguna parte que podría ser porque el directory estaba vacío en Subersion, así que traté de enviar un file ficticio a SVN por separado y luego ejecuté:

 git svn fetch A dummy.txt r10744 = 89294ba713c6fed368f3b879c8dc7744b1015308 (refs/remotes/git-svn) 

Sin embargo, no puedo encontrar el file dummy.txt en mi git repo y tanto rebase como dcommit continuarán mostrando el mismo post de error. ¿Qué hice mal?

Su twig desprotegida no proviene de subversión, por lo que git svn no sabe cómo trabajar con ella.

Git lo hace, sin embargo, entonces lo que tienes que hacer es usar la database de git rebase para volver a git-svn ( refs/remotes/git-svn ). Entonces el historial contendrá commits provenientes de subversion y git svn dcommit sabrá dónde hacerlo.

Otra cosa es que los cambios deben colocarse en el subdirectory correcto antes de tratar de volver a establecer una base de ellos, porque git rebase no admite moverse al subdirectory. git merge hace, a través de la estrategia del subdirectory , pero al usar merge se exportará a Subversion como una única confirmación. Si desea exportar el historial completo, y no lo tiene en el directory correcto en todas las confirmaciones , deberá usar git filter-branch para corregirlo.

La respuesta proporcionada por Jan da la razón del error que encontré y apunta a la vieja y git rebase --onto como la solución adecuada, pero carece de los commands reales.

Inicialmente propuse esos commands como una edición de su respuesta, pero fue rechazada, así que aquí va:

 git checkout -b svnrebase git-svn # create a temporary branch git cherry-pick master~1 # cherry pick the first commit git rebase --onto svnrebase master~1 master # rebase the 2nd through current commit git svn dcommit # finally commit the results to svn 

TEN master~1 CUENTA que master~1 debe cambiarse para hacer reference a tu primera confirmación con el maestro de git. Aquí, suponemos que tenemos un repository git con solo dos commits.

Es necesario crear una bifurcación temporal y seleccionar el primer commit para master, ya que rebase --onto solo rebase --onto el range de modificaciones realizadas después del master~1 (y la reference master~2 no existiría con solo dos commits).