¿Por qué git-svn dcommit deja commits duplicados en mi git repo? ¿Puedo detenerlo haciendo eso?

Question

Mi flujo de trabajo típico git-svn es:

git checkout -b story-xyz 
git commit -a -m "work" 
git commit -a -m "more work" 
git checkout master 
git svn fetch 
git merge remotes/trunk 
git checkout story-xyz 
git rebase master (sometimes with -i) 
git checkout master 
git merge story-xyz 

En este punto tengo mi master y story-xyz ramas apuntando a la misma confirmación, uno o más comete por delante de remotes/trunk. Todo desde remotes/trunk está en una historia lineal.

last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz] 

entonces corro

git svn dcommit 

esperaba ver las confirmaciones entre remotes/trunk y master revisiones Subversion convertido, y terminar con una sola historia lineal con remotes/trunk, master y story-xyz todos apuntando a la última revisión, así:

last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk] 

Mis revisiones de Subversion entran bien, pero termino con una estructura de dos ramas. La raíz común de la rama es Subversion HEAD antes de comprometerme. Ambas ramas contienen la misma serie de confirmaciones, en el sentido de que contienen las mismas diferencias. La rama story-xyz está a la cabeza de una rama, remotes/trunk y master en el otro:

last svn commit <--- work <--- more work [master, remotes/trunk] 
        | 
        \- work <--- more work [story-xyz] 

El confirmaciones Git que tenía antes de ejecutar git svn dcommit están en la rama inferior (story-xyz), con mi git commit mensajes, git nombre de usuario y correo electrónico, y git commit timestamps. Los commits en la rama superior son nuevos commits de git. Usan mi nombre de usuario de Subversion, la marca de tiempo cuando ejecuté el dcommit, y los mensajes de confirmación tienen el campo git-svn-id adjunto a ellos.

Todo está bien, y puedo seguir trabajando. El problema es que miro en gitk y veo lo que parece una rama no fusionada story-xyz. Es bastante difícil distinguir la diferencia entre una rama de historia que he fusionado de nuevo en master, y una que no tengo. La forma más obvia de detectarlo son los mensajes de confirmación duplicados. Podría eliminar la rama story-xyz, pero parece que no estoy usando git correctamente y he perdido parte de mi historial.

¿Me falta algo que podría detener git-svn de hacer esto? ¿O es solo una de las formas en que la interacción con Subversion diluye el poder y la libertad de git?

Answer 1

No creo que te estés perdiendo nada. Sin embargo, puedes estar haciendo un trabajo innecesario. En este caso, tiene dos punteros al compromiso de "más trabajo", y le está pidiendo a git-svn que mueva uno de ellos. El otro todavía se queda donde está.

Realmente no necesita la rama master. A Git-svn no le importa qué rama estás comprometiendo. IIRC, utiliza el primer svn-remote que puede encontrar entre los antepasados ​​del commit actual.

voy a ofrecer otra versión del flujo de trabajo:

git checkout -b story-xyz remotes/trunk 
git commit -a -m "work" 
git commit -a -m "more work" 
git svn fetch 
git rebase remotes/trunk (with -i, perhaps) 
git svn dcommit 

Esto debe darle un árbol sin la rama adicional. Sin embargo, debes tener cuidado con las fusiones rápidas.