Quelles sont les différences entre le point double «..» et le point triple «…» dans les plages de validation Git?


Réponses:


251

Cela dépend si vous utilisez une logcommande ou une diffcommande. Dans le logcas, c'est dans la man git-rev-parsedocumentation:

Pour exclure les validations accessibles depuis une validation, une notation de préfixe ^ est utilisée. Par exemple, ^ r1 r2 signifie que les commits accessibles depuis r2 mais excluent ceux accessibles depuis r1.

Cette opération d'ensemble apparaît si souvent qu'il y a un raccourci pour cela. Lorsque vous avez deux validations r1 et r2 (nommées selon la syntaxe expliquée dans SPÉCIFICATION DES RÉVISIONS ci-dessus), vous pouvez demander des validations qui sont accessibles à partir de r2 à l'exclusion de celles qui sont accessibles à partir de r1 par "^ r1 r2" et elles peuvent être écrites comme "r1..r2".

Une notation similaire "r1 ... r2" est appelée différence symétrique de r1 et r2 et est définie comme "r1 r2 --not $ (git merge-base --all r1 r2)". C'est l'ensemble des commits qui sont accessibles depuis l'un des r1 ou r2 mais pas des deux.

Ce qui signifie essentiellement que vous obtiendrez tous les commits qui se trouvent dans l'une des deux branches, mais pas dans les deux.

Dans le diffcas, c'est dans la man git-diffdocumentation:

  git diff [--options] <commit>...<commit> [--] [<path>...]

      This form is to view the changes on the branch containing and up to
      the second <commit>, starting at a common ancestor of both
      <commit>. "git diff A...B" is equivalent to "git diff
      $(git-merge-base A B) B". You can omit any one of <commit>, which
      has the same effect as using HEAD instead.

Ce qui est un peu flou. Fondamentalement, cela signifie qu'il ne montre que les différences dans cette branche par rapport à une autre branche: il recherche le dernier commit commun avec le premier commit que vous lui avez donné, puis diffère le deuxième committish. C'est un moyen facile de voir quels changements sont effectués dans cette branche, par rapport à cette branche, sans prendre en compte les changements dans cette branche uniquement.

Le ..est un peu plus simple: dans le git-diffcas, c'est la même chose que a git diff A Bet juste diffère A contre B. Dans le logcas, il montre tous les commits qui sont en B mais pas en A.


31
C'est assez ridicule de voir comment le sens de ..et ...est exactement échangé pour log et diff: log A..Best le changement de la base de fusion en B, ce qui diff A...Bfait
phiresky

1
@phiresky Ouais, c'est vraiment une mauvaise utilisation. Je recommande de ne pas utiliser les notations de points pour git diff.
wisbucky

2
Est-ce à dire A...B== A..B + B..A?
Danon

2
@Danon car git logc'est absolument oui
maoizm

659

Utilisation des plages de validation avec le journal Git

Lorsque vous utilisez des plages de validation comme ..et ...avec git log, la différence entre elles est que, pour les branches A et B,

git log A..B

vous montrera tous les commits que B a que A n'a pas , tandis que

git log A...B

vous montrera à la fois les validations que A a et que B n'a pas, et les validations que B a que A n'a pas, ou en d'autres termes, il filtrera toutes les validations que A et B partagent, montrant uniquement les engagements qu'ils ne partagent pas tous les deux .

Visualisation avec les diagrammes de Venn et les arbres de validation

Voici une représentation visuelle de git log A..B. Les validations que contient la branche B qui n'existent pas dans A sont ce qui est retourné par la plage de validation, et sont surlignées en rouge dans le diagramme de Venn, et entourées en bleu dans l'arborescence de validation:

 Diagramme "git log A..B"Arbre 1

Ce sont les diagrammes pour git log A...B. Notez que les commits partagés par les deux branches ne sont pas renvoyés par la commande:

 Diagramme "git log A ... B"Arbre 2

Création de la plage de validation à trois points ... plus utile

Vous pouvez rendre la plage de validation à trois points ...plus utile dans une commande de journal en utilisant l' --left-rightoption pour afficher les validations appartenant à quelle branche:

$ git log --oneline --decorate --left-right --graph master...origin/master
< 1794bee (HEAD, master) Derp some more
> 6e6ce69 (origin/master, origin/HEAD) Add hello.txt

Dans la sortie ci-dessus, vous verrez les validations qui appartiennent à mastersont préfixées avec <, tandis que les validations qui appartiennent à origin/mastersont préfixées avec >.

Utilisation des plages de validation avec Git Diff

Un jour, je pourrais ajouter ma propre explication sur le fonctionnement des plages de validation git diff, mais pour l'instant, vous voudrez peut-être vérifier quelles sont les différences entre le double point ".." et le triple point "..." dans Git diff commit gammes? .

Voir également


35
Cette réponse explique en fait la différence avec un texte concis, des exemples et des images. Je l'aime beaucoup mieux que la réponse actuellement la mieux votée qui ne fait que citer la documentation peu claire. (tl; dr grâce à cette réponse je comprends vraiment la différence.)
aerique

4
@Cupcake pourriez-vous ajouter le sens ... dans git diff?
Marius

1
@Marius en fait, maintenant que vous en parlez, je vais continuer et lier à cette autre question dans ma réponse, pour les futurs lecteurs comme vous.

2
N'est-ce pas vraiment le contraire? dig diff a..b est TOUS diffs, ou fondamentalement le même que git diff a b. Alors que git dif a ... b est SEULEMENT les modifications apportées par b depuis la dérivation de a.
wejrowski

2
Au moins pour git log. Pour git diff, peut-être que les choses sont inversées: stackoverflow.com/questions/7251477/…
Benjamin Atkin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.