git merge contra una revisión de base arbitraria (git-svn)

Estoy usando git-svn para el desarrollo fuera de línea en el repository de Subversion de mi empresa, que es el depósito de logging del proyecto. Para habilitar la visibilidad de la administración, debo mantener mis twigs de características en SVN. A veces necesito fusionar los cambios de nuestro tronco a una twig de características varias veces durante la vida de la twig. Como tengo que mantener la twig actualizada en SVN, tengo que fusionarme; No puedo volver a establecer la base de compromisos una vez que se envían a SVN. Además, git svn dcommit elimina el segundo padre de las git svn dcommit de fusión. Eso significa que en las fusiones después de la primera git merge identifica la raíz de la sucursal como la base de combinación en lugar del padre de fusión más reciente. Por lo tanto, intenta volver a fusionar los cambios que ya se han fusionado, lo que prácticamente garantiza conflictos desagradables.

Cuando me fusiono en SVN, especifico manualmente la revisión base:

 svn merge -r 49262:49608 $svn/trunk 

¿Hay alguna forma de hacer una fusión en Git con una revisión básica especificada manualmente así?

Actualizar:

Tenga en count que necesito especificar dos revisiones, tanto la base como la revisión principal. Tengo una historia como

 trunk: A -- B -- C -- D -- H -- I \ \ feature: E -- F -- G -- J -- K 

pero git svn dcommit ha eliminado la relación principal entre G y D Necesito ejecutar una fusión de I on a K con una base de D Simplemente corriendo

 $ git checkout feature $ git merge trunk 

Intentará fusionar I on a K con una base de B lugar de D , lo que vuelve a aplicar C y D da como resultado conflictos de fusión extremos. Con SVN, ejecutaría un command como

 $ svn switch $svn/feature $ svn merge -r D:I $svn/trunk 

pero git merge no tiene una opción para especificar la revisión base D Estoy buscando algo así como

 $ git merge --base D trunk 

pero tal opción no parece existir.

Solutions Collecting From Web of "git merge contra una revisión de base arbitraria (git-svn)"

(Editar: para una forma de nivel inferior de hacer esto, ver revisiones anteriores, aunque el path es más rápido)

  • hacer un commit de nonce con el tree de características criado en la base de combinación correcta

     git checkout `git commit-tree -p $D -m - feature^{tree}` 
  • fusionar el tronco en eso como de costumbre

     git merge trunk --no-commit git commit # the two-stepper gets the commit message someplace known 
  • cometer el tree fusionado como la nueva feature punta

     git commit-tree -p feature -p trunk -F .git/COMMIT_EDITMSG HEAD^{tree} \ | xargs git checkout -B feature 

Puede probar git merge <commit hashcode> donde se puede encontrar el código hash de la confirmación usando git log

Actualizar:

Según su revisión, creo que lo que está buscando es lo siguiente. Comienza haciendo git branch D Debería poder get el hash de confirmación para D haciendo el git status . Luego, haz la git checkout feature . Luego haz git merge newBranchFromD . Esto colocará el estado de la característica en un estado fusionado, desde D, desde el tronco.

También puedes, para mantener un historial de confirmaciones más limpio, hacer un git rebase newBranchFromD después de verificar la twig de características. Tenga cuidado, esto inserta H en el lugar correcto en el historial de confirmaciones, para que termine con:

            trunkAtD: - H - I
                        /
 tronco: A - B - C - D - H - I
     \ \
     function: E - F - G - H - I - J - K

Esto es un poco diferente de un commit de fusión, ya que rebase coloca todos los commits en order cronológico en tu historial de commits. Otra opción que tienes es usar –squash en tu confirmación, para que la fusión no intente autocomprometida.

Use rebase con precaución, ya que puede causar resultados inesperados si no se usa cuando sabe lo que sucede con él.

Esto es lo que hicimos. Primero encontramos el hash del compromiso de fusión que había perdido su 'fusión' – MISSING_MERGE, Segundo encontramos el commit que ese commit se había fusionado en – MERGED_POINT.

Luego fuimos a la twig receptora y creamos un compromiso falso

 git merge -s ours MERGED_POINT --no-commit git commit -m "Fake commit because MISSING_MERGE is not marked as a merge commit" 

Entonces podemos ver

 git merge-base OURS THEIRS 

que ahora tenemos la base correcta de nuevo.