221 votes

Comment "git show" un commit de fusion avec une sortie de diff combinée même si chaque fichier modifié est en accord avec l'un des parents ?

Après avoir fait une fusion "simple" (sans conflits), git show ne montre généralement que quelque chose comme

commit 0e1329e551a5700614a2a34d8101e92fd9f2cad6 (HEAD, master)
Merge: fc17405 ee2de56
Author: Tilman Vogel <email@email>
Date:   Tue Feb 22 00:27:17 2011 +0100

Merge branch 'testing' into master

C'est parce que, pour les fusions, git show utilise le format diff combiné qui omet les fichiers qui sont en accord avec l'une ou l'autre des versions parentes.

Existe-t-il un moyen de forcer git à afficher toutes les différences en mode diff combiné ?

Faire git show -m montrera les différences (en utilisant les différences par paires entre la nouvelle version et toutes les versions parentes respectivement) mais je préférerais avoir cela avec les différences marquées par +/- dans les colonnes respectives comme en mode combiné.

2 votes

@ Tilman Vogel : veuillez revoir la réponse acceptée - Il semble qu'il y ait de meilleures réponses.

2 votes

@Jayan Alors que les autres réponses sont plus populaires parce qu'elles contiennent des conseils utiles, elles ne s'approchent pas plus de mon problème que de faire seulement des différences à double sens. Je cherchais une différence à trois voies.

287voto

rip747 Points 4033

Regardez le message de validation :

commit 0e1329e551a5700614a2a34d8101e92fd9f2cad6 (HEAD, master)
Merge: fc17405 ee2de56
Author: Tilman Vogel <email@email>
Date:   Tue Feb 22 00:27:17 2011 +0100

Merge branch 'testing' into master

remarquez la ligne :

Merge: fc17405 ee2de56

prenez ces deux identifiants de commit et inversez-les. donc pour obtenir la différence que vous voulez, vous devez faire :

git diff ee2de56...fc17405

pour afficher uniquement les noms des fichiers modifiés :

git diff --name-only ee2de56..fc17405

et pour les extraire, vous pouvez ajouter ceci à votre gitconfig :

exportfiles = !sh -c 'git diff $0 --name-only | "while read files; do mkdir -p \"$1/$(dirname $files)\"; cp -vf $files $1/$(dirname $files); done"'

puis l'utiliser en faisant :

git exportfiles ee2de56..fc17405 /c/temp/myproject

0 votes

Merci pour la suggestion mais je pense qu'elle ne résout pas mon problème. En raison du balisage et du formatage limités des commentaires, j'ai ajouté mon commentaire à votre réponse. Désolé pour cela ! Doit être révisé par les pairs avant d'être visible.

6 votes

Il semble que mon édition ait été refusée. En résumé : votre diff ne montre pas quels ajouts proviennent de quelle branche. Et vous ne pouvez pas distinguer si les changements ont été ajoutés dans la deuxième branche ou supprimés dans la première.

53 votes

Une meilleure solution est git diff fc17405...ee2de56 - cela montrera tous les changements sur ee2de56 qui sont accessibles à partir des commits sur fc17405, ce qui je crois est ce que vous voulez. Notez les 3 points au lieu de 2.

12voto

side2k Points 846

Vous pouvez créer une branche avec HEAD réglé sur un commit avant la fusion. Ensuite, vous pouvez le faire :

git merge --squash testing

Cela va fusionner, mais pas commettre. Alors :

git diff

4voto

patthoyts Points 8978

Je pense que vous avez juste besoin de "git show -c $ref". En essayant ceci sur le dépôt git sur a8e4a59, on obtient un diff combiné (plus/moins de caractères dans l'une des 2 colonnes). Comme le manuel de git-show le mentionne, il délègue en grande partie à 'git diff-tree' donc ces options semblent utiles.

4 votes

Non, pour une fusion "simple", git show -c $ref montre le même résultat que celui que j'ai cité, c'est-à-dire aucune différence. -c sélectionne un mode de diff combiné très similaire au mode par défaut pour les commits de fusion, qui est '--cc', cf. git help show y git help diff-tree . Les deux omettent complètement les fichiers qui sont en accord avec l'une ou l'autre des versions parentes de ce fichier.

0 votes

a8e4a59 n'entre effectivement pas dans la catégorie des merge commits, je veux dire. Ce merge commit contient en effet un fichier qui diffère de ses deux versions parentes. Documentation/git-fast-import.txt a des éléments ajoutés par un parent et d'autres par l'autre. Il en résulte une sortie non vide de git diff-tree --cc . Cependant, seuls les changements dans ce cas "conflictuel" sont montrés. Pour tous les résultats de la fusion "propre", regardez git show -m a8e4a59 ne sont pas montrés du tout.

1 votes

@TilmanVogel : Merci d'avoir signalé que les fusions de fichiers "inintéressantes" ne sont pas prises en compte dans l'évaluation de l'efficacité de l'aide. git show -c sortie. ( man git-diff-tree dit bien "En outre, il ne répertorie que les fichiers qui ont été modifiés de tous les parents", mais pour ma part, je n'avais certainement pas repéré cela).

3voto

gurugray Points 39

Dans votre cas, il vous suffit de

git diff HEAD^ HEAD^2

ou simplement hacher pour vous engager :

git diff 0e1329e55^ 0e1329e55^2

4 votes

Non, ça fait juste une simple différence bidirectionnelle entre les deux parents. Ce que je demandais, c'était un mode qui montre simultanément la différence entre les deux parents. git merge-base HEAD^ HEAD^2 y HEAD^ y HEAD^2 dans le même style que ce qui est fait pour les fichiers qui ont été fusionnés avec des conflits.

-3voto

apenwarr Points 4956

Non, il n'y a aucun moyen de faire cela avec git show . Mais ce serait certainement agréable parfois, et ce serait probablement relativement facile à implémenter dans le code source de git (après tout, il suffit de lui dire de pas de couper ce qu'il considère comme une sortie superflue), donc le patch pour le faire serait probablement accepté par les mainteneurs de git.

Faites attention à ce que vous souhaitez, cependant ; la fusion d'une branche avec un changement d'une ligne qui a été bifurquée il y a trois mois aura toujours une incidence sur le résultat de la fusion. énorme par rapport à la ligne principale, et donc une telle différence complète serait presque complètement inutile. C'est pourquoi git ne l'affiche pas.

14 votes

Ne dites pas "pas moyen de le faire", car il est clair que c'est possible - voir les autres réponses. C'est très trompeur de dire cela.

1 votes

Git show HEAD^...HEAD ; # selon la solution de @hesham_EE.

0 votes

Git show HEAD~1...HEAD~0 --name-only ; # meilleure syntaxe. Pour itérer les pr's.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X