Pourquoi git-svn dcommit laisse-t-il des doubles dans mon repo git? Puis-je l'empêcher de faire ça?

Question

Mon git-svn flux de travail est typique:

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 

À ce stade, j'ai mes branches master et story-xyz pointant vers la même livraison, un ou plusieurs engage en avance sur remotes/trunk. Tout depuis remotes/trunk est dans une histoire linéaire.

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

Je lance alors

git svn dcommit 

Je me attendais à voir les commits entre remotes/trunk et master deviennent des révisions Subversion, et se retrouver avec une seule histoire linéaire avec remotes/trunk, master et story-xyz tout en montrant la dernière révision, comme ça:

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

Mes révisions Subversion vont dans bien, mais je me retrouve avec une structure à deux branches. La racine commune de la branche est la tête de Subversion avant que je m'engage. Les deux branches contiennent la même série de commits, en ce sens qu'elles contiennent les mêmes différences. La branche story-xyz est à la tête d'une branche, remotes/trunk et master à l'autre:

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

Le git engage que j'avais avant d'exécuter git svn dcommit sont sur la branche inférieure (story-xyz), avec mon git commit messages, git nom d'utilisateur et e-mail, et git commit horodateurs. Les validations sur la branche supérieure sont de nouveaux commit git. Ils utilisent mon nom d'utilisateur Subversion, l'horodatage lorsque j'ai exécuté le dcommit et les messages de validation ont le champ git-svn-id ajouté.

Tout est OK, et je peux continuer à travailler. Le problème est que je regarde dans gitk et vois ce qui ressemble à une branche non fusionnée story-xyz. Il est assez difficile de faire la différence entre une branche d'histoire que j'ai fusionnée en master, et une autre que je n'ai pas. La manière la plus évidente de le repérer est le message de validation en double. Je pourrais supprimer la branche story-xyz, mais j'ai l'impression de ne pas utiliser git correctement et j'ai perdu une partie de mon histoire.

Ai-je besoin de quelque chose qui empêcherait git-svn de le faire? Ou est-ce juste une des façons d'interagir avec Subversion dilue le pouvoir et la liberté de git?

Answer 1

Je ne pense pas que vous manquiez vraiment quelque chose. Cependant, vous faites peut-être un travail inutile. Dans ce cas, vous avez deux pointeurs sur le commit "more work", et vous demandez à git-svn de déplacer l'un d'entre eux. L'autre reste toujours là où il est.

Vous n'avez pas vraiment besoin de la branche master. Git-svn ne se soucie pas de la branche que vous décrivez. IIRC, il utilise le premier svn-remote qu'il peut trouver parmi les ancêtres du commit actuel.

Je vais proposer une autre version du flux de travail:

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 

Cela devrait vous donner un arbre sans branche supplémentaire. Cependant, vous devez faire attention aux fusions rapides.