git-svn problema con git add –patch que da lugar a conflictos

Básicamente cuando quiero confirmar dos cambios por separado en el mismo file que resultó de una git add --patch <file> , git svn rebase más tarde lanza conflictos 1-2 al realizar el segundo cambio cuando se usa git add para el segundo cambio .

así que básicamente estoy haciendo esto (estoy en la twig principal y he buscado el repository svn):

 git checkout -b feature ... make two unrelated changes to file test.txt... git add --patch test.txt ... add first change but ignore second one git commit -m "change1" git stash git checkout master git merge feature git svn rebase git svn dcommit git checkout feature git stash apply 

ahora aquí hay dos forms de hacerlo, primero la que funciona:

 git add --patch test.txt ... select everything (which is the second change in this case) git commit -m "change 2" git checkout master git merge feature git svn rebase git svn dcommit 

aquí está el que no funciona:

 git add test.txt #notice there's no --patch git commit -m "change 2" git checkout master git merge feature git svn rebase #yields a conflict 

Entonces, ¿por qué cuando uso git add --patch para el segundo cambio, puedo comprometerme con el repository svn sin problemas, pero cuando uso git add para el segundo cambio, resulta en un conflicto? Soy bastante nuevo en git, por lo que esta podría ser una pregunta estúpida, pero según lo veo, ambos sets de commands deberían hacer exactamente lo mismo.

¿Por qué creas una twig para tus 2 commits y luego te fusionas? Supongo que esto podría dar problemas, ya que las fusiones en git funcionan de forma diferente a como funcionan en svn.

esto debería funcionar ("debería", pero estoy bastante seguro de que lo hace):

 # on master, no need to create a branch $ git add -p file $ git commit -m "first set of changes" $ git add file $ git commit -m "the remaining changes" # apply your commit on top of eventually new changes upstream $ git svn rebase # commit your 2 commits to svn $ git svn dcommit 

en svn branches son solo copys de un directory (más a menudo el directory troncal), y las svn:mergeinfo fusión no difieren de las confirmaciones normales (excepto la nueva propiedad svn:mergeinfo comienza con svn 1.6)

los commits en git son diferentes, cada commit almacena un enlace a su commit padre. svn no necesita esto, ya que simplemente puede usar REV-1. merge commits en git así tienen múltiples padres (la twig de fusión y la twig fusionada)

No sé qué sucederá si usted entrega un git a svn, pero probablemente solo cometerá el commit de fusión, sin historial (el post es algo así como "fusionar twig 'bla' en 'maestro').

cuando ejecuta svn commit solo sus nuevos cambios se envían al server para ahorrar ancho de banda. ahora, las fusiones en el trabajo de git son diferentes y la diferencia con las versiones anteriores probablemente no sea la git svn dcommit , por eso git svn dcommit falla.

incluso lo dice en la documentation de git svn: no combine twigs usando git y comprímalas con svn, lo más probable es que estropee su historial

No se recomienda ejecutar git merge o git pull en una sucursal de la que planea comprometerse. Subversion no representa fusiones de ninguna manera razonable o útil; para que los usuarios que usan Subversion no puedan ver las fusiones que hayas realizado. Además, si se fusiona o tira de una twig git que es un espejo de una twig SVN, dcommit puede comprometerse con la twig incorrecta. git svn docs