git-svn fusionne et commente

Question

Nous utilisons git-svn pour gérer les branches d'un dépôt 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 voudrait utiliser git-svn pour fusionner les changements de branche en trunk. Le problème que nous voyons est que les messages de validation pour toutes les opérations de fusion semblent avoir été faits par l'utilisateur Y, alors que le changement réel de branche a été fait par l'utilisateur X.

Y at-il un moyen d'indiquer à git-svn que lors de la fusion, utilisez le message/auteur de commit original pour un changement donné plutôt que la personne effectuant la fusion?

Answer 1

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

Il ya 2 problèmes ici. La première est que svn ne stocke que le committer, pas l'auteur d'un patch comme le fait git. Donc, quand Y commet les fusions à trunk, svn enregistre seulement son nom, même si les patches ont été écrits par X. Ceci est une caractéristique étonnante de git, incroyablement simple mais vitale pour les projets open source qui attribuait des changements à l'auteur peut éviter problèmes juridiques sur la route.

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

Je viens d'essayer avec git 1.6.0.2 et il "perd" des informations comparé à faire la même opération avec svn merge. Dans svn 1.5, une nouvelle fonctionnalité a été ajoutée aux méthodes d'enregistrement et d'annotation, de sorte que -g svn log sur le tronc serait quelque chose de sortie comme 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 engage r5, qui intègre la change de X sur la branche dans le tronc. Le format du journal est pas vraiment grand, mais il est dans son propre sur svn blâme -g:

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

ici en supposant Y engage que le tronc, on peut voir qu'une ligne a été editted par X (sur la branche) et fusionné. Donc, si vous utilisez svn 1.5.2, vous êtes peut-être mieux de fusionner avec le vrai client svn pour l'instant. Bien que vous perdiez des informations de fusion dans git, il est généralement assez intelligent pour ne pas se plaindre. Mise à jour: Je viens d'essayer ceci avec git 1.7.1 pour voir s'il y a eu des progrès dans l'intérim. La mauvaise nouvelle est que la fusion dans git ne remplit toujours pas les valeurs svn: mergeinfo, donc git merge suivi de git svn dcommit ne mettra pas svn: mergeinfo et vous perdrez les informations de fusion si le dépôt Subversion est la source canonique, ce qui est probablement le cas. La bonne nouvelle est que git svn clone lit dans les propriétés svn: mergeinfo pour construire un meilleur historique de fusion, donc si vous utilisez correctement svn merge (il faut fusionner des branches complètes) alors le clone git semblera correct aux utilisateurs git.

Answer 2

Vous pouvez utiliser des greffons pour enseigner à git les fusions qui ne sont pas indiquées dans l'objet commit en question.

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

Trouver cette information est assez facile: trouver donné la fusion commit en question, vous savez déjà $merge_sha1 et $parent1_sha1.Classiquement, le message de validation d'un tel engagement contiendra le numéro de révision SVN du second parent commettre, que vous traduisez simplement à l'ID de validation correspondant:

git svn find-rev r$revnum $branch 

Presto, vous avez tous les 3 éléments d'information que vous devez créer la greffe.

Answer 3

Essayez d'utiliser le --add-auteur de et --use-log-auteur options pour git-svn.