git-svn fusionne et engage les détails

Question

nous utilisons git-svn pour gérer les branches d'un référentiel SVN. Nous sommes confrontés au problème suivant: après un certain nombre de validations par l'utilisateur X dans la branche, l'utilisateur Y souhaite utiliser git-svn pour fusionner les modifications d'une branche à une ligne de réseau. Le problème que nous constatons est que les messages de validation pour toutes les opérations de fusion individuelles semblent avoir été créés par l'utilisateur Y, alors que le changement de branche réel a été effectué par l'utilisateur X.

Existe-t-il un moyen d'indiquer à git-svn qu'en cas de fusion, utilisez le message / l'auteur de validation d'origine pour une modification donnée plutôt que la personne effectuant la fusion?

Answer 1

La page de manuel git-svn vous recommande de ne pas utiliser la fusion . "" Nous vous recommandons d'exécuter git-svn fetch et de rebaser (et non de tirer ou de fusionner) ". Cela dit, vous pouvez faire ce que vous aimez: -)

Il y a 2 problèmes ici. Premièrement, svn ne stocke que le commiter , et non l'auteur d'un patch comme le fait git. Ainsi, lorsque Y valide les fusions dans trunk, svn n'enregistre que son nom, même si les correctifs ont été créés par X. Il s'agit d'une fonctionnalité étonnante de git, étonnamment simple et pourtant essentielle pour les projets open source attribuant des modifications à l'auteur peut éviter des problèmes juridiques sur la route.

Deuxièmement, git ne semble pas utiliser les fonctionnalités relativement nouvelles de svn merge. Cela peut être une chose temporaire, car git est activement développé et de nouvelles fonctionnalités sont ajoutées à tout moment. Mais pour l'instant, il ne les utilise pas.

Je viens d’essayer avec git 1.6.0.2 et il "perd" informations comparées à la même opération avec svn merge. Dans svn 1.5, une nouvelle fonctionnalité a été ajoutée aux méthodes de journalisation et d'annotation, de sorte que svn log -g sur le tronc génère un résultat similaire à celui-ci pour une fusion:

------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line

Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5

Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5

Create a branch

Ici, Y valide r5, qui intègre les modifications de X sur la branche dans le tronc. Le format du journal n’est pas vraiment génial, mais il prend tout son sens sur svn blame -g:

       2          Y int main()
       2          Y {
G      4          X   return 1;
       2          Y }

Dans l’hypothèse où Y ne commet que sur le tronc, on peut voir qu’une ligne a été modifiée par X (sur la branche) et fusionnée.

Donc, si vous utilisez svn 1.5.2, vous feriez mieux de fusionner avec le vrai client svn pour le moment. Bien que vous perdriez les informations de fusion dans git, il est généralement assez intelligent pour ne pas vous plaindre.

Mise à jour: Je viens d’essayer cela avec git 1.7.1 pour voir s’il ya eu des progrès entre-temps. La mauvaise nouvelle est que la fusion dans git ne remplit toujours pas les valeurs de svn: mergeinfo, aussi fusion de git suivi de git svn dcommit ne définira pas svn: mergeinfo et vous perdrez fusionner les informations si le référentiel Subversion est la source canonique, ce qui est probablement le cas. La bonne nouvelle est que git svn clone est lu dans les propriétés svn: mergeinfo pour créer un meilleur historique de fusion. Par conséquent, si vous utilisez svn merge correctement (il faut fusionner toutes les branches) alors le clone git sera correct pour les utilisateurs de git.

Answer 2

Vous pouvez utiliser des greffes pour enseigner à git des fusions qui ne sont pas indiquées dans l'objet de validation en question.

echo "$merge_sha1 $parent1_sha1 $parent2_sha1" >> .git/info/grafts

Il est assez facile de trouver cette information: étant donné que vous avez trouvé la validation de fusion en question, vous connaissez déjà $ merge_sha1 et $ parent1_sha1 . Classiquement, le message de validation d'une telle validation contient le numéro de révision SVN de la deuxième validation parent, que vous traduisez simplement en ID de validation correspondant:

git svn find-rev r$revnum $branch

Presto, vous avez les 3 informations nécessaires pour créer le greffon.

Answer 3

Essayez d'utiliser les options --add-author-from et --use-log-author pour git-svn.