2017-02-07 3 views
1

On suppose quelque chose comme ce qui suit:Calculez les dépendances d'un engagement que nous essayons de choisir la cerise

      HEAD/master  
          | 
A<--B<--C<--D<--E<--F<--G<--J 
     ^
     official 

official est une branche.
Je voulais sélectionner 2 commits à official branche e.g. E et J
Ces deux validations étaient des correctifs affectant les mêmes 3 fichiers.
Quand j'ai fait git cherry-pick E ça s'est bien passé mais quand j'ai fait git cherry-pick J j'ai eu quelques conflits.
En regardant les diffs je me suis rendu compte que je devais aussi sélectionner le commit F qui a fait un changement dans deux de ces 3 fichiers qui changeaient fondamentalement un changement de définition de méthode et J a été fait en plus de cela.
il était donc facile de fixer en faisant juste git cherry-pick F && git cherry-pick J
Question:
Si je n'étais pas au courant des changements effectués dans ces fichiers et F était un commit grand changement allouent de nombreux fichiers: Y at-il une autre façon de comprendre le qui commettre un commit que nous essayons de choisir dépend sans manuellement faire un git log sur le fichier et aller commettre par commit?

Répondre

0

J'ai eu quelques [Merge] conflits ... Y at-il une autre façon de comprendre sur laquelle engager une commettons nous essayons de choisir cerise dépend ...

Pas vraiment, non.

... sans faire manuellement un journal git sur le fichier et aller commettre par commit?

Même cela ne le fera pas nécessairement, du moins pas sans penser réellement au problème. Considérons le bit suivant du code C:

void f(int x) { 
    int i; 

    /* 
    * additional lines here, enough to mess with git context 
    * since that only looks at +/- 3 lines around each patch 
    * segment 
    */ 

    for (i = 0; i < x; i++) 
     do_something(i); 
} 

Supposons que l'on commit intermédiaire introduit une variable j supplémentaire, puis une validation ultérieure des changements do_something(i)-do_something(j). Si vous choisissez uniquement le le commit suivant, Git changera volontiers la ligne sans conflit, mais le code ne sera plus compilé, puisqu'il n'y a pas de int j dans la fonction f. Cela dit, il serait possible d'écrire un outil qui analyse git show sortie pour chaque validation intermédiaire, détermine quelles lignes sont modifiées (par rapport à la version dans l'arbre de travail, plutôt que d'utiliser les numéros réels dans chaque diff , puisque ceux-ci peuvent dépendre d'un précédent diff ignoré), et vous indique les validations qui modifient les régions en conflit. Mais je ne connais pas un tel outil.

+0

Alors, quel est votre flux de travail dans des cas comme celui-ci? Qu'avez-vous trouvé le plus efficace? – Jim

+0

@Jim: généralement, beaucoup d'inspection des commits-essentiellement, ce que vous avez fini par faire. Les pics de sélection complexes devraient être rares en partie parce que les outils ne les traitent pas bien, et les outils ne fonctionnent pas bien en partie parce qu'ils sont rares, ce qui est en quelque sorte un piège. – torek