Signification des doubles tirets Git Checkout

Quelle est la signification des doubles tirets avant le nom de fichier dans cette commande git?

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

Sont-ils obligatoires? Est-ce équivalent à

git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt

Supposons que j'ai un fichier nommé path/to/file.txtdans mon référentiel Git et que je souhaite annuler les modifications.

git checkout path/to/file.txt

Supposons maintenant que le fichier soit nommé master...

git checkout master

Oups! Cela a plutôt changé de branche. Le --sépare l'arborescence que vous souhaitez extraire des fichiers que vous souhaitez extraire.

git checkout -- master

Cela nous aide également si certains monstres ajoutent un fichier nommé -fà notre référentiel:

git checkout -f      # wrong
git checkout -- -f   # right

Ceci est documenté dans git-checkout: Argument Disambiguation .

Le double tiret «-» signifie «drapeaux de fin de ligne de commande», c'est-à-dire qu'il indique à la commande précédente de ne pas essayer d'analyser ce qui vient après les options de ligne de commande.

Notez que vous n'auriez pas besoin, puisque Git 2.5 (Q2 2015) d'un ' --' si votre argument inclut un caractère générique ( *)

Une heuristique pour aider la " git <cmd> <revs> <pathspec>" convention de ligne de commande à capturer les chemins mal typés est de s'assurer que tous les paramètres non rev dans la dernière partie de la ligne de commande sont les noms des fichiers dans l'arborescence de travail, mais cela signifie que " git grep $str -- \*.c" doit toujours être sans ambiguïté avec " --", car personne sain d'esprit ne créera un fichier dont le nom est littéralement astérisque-point-voir.

Git 2.5 perd l'heuristique pour déclarer qu'avec une chaîne générique, l'utilisateur voulait probablement nous donner une spécification de chemin .

git checkout 'a*'
# same as
git checkout -- 'a*'

Voir commit 28fcc0b (02 mai 2015) par Duy Nguyen ( nguyenlocduy) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 949d167 , 19 mai 2015)}

pathspec: éviter le besoin de " --" lorsque le caractère générique est utilisé

Lorsque " --" est absent de la ligne de commande et qu'une commande peut prendre à la fois des tours et des chemins, l'idée est que si un argument peut être vu à la fois comme un SHA-1 étendu et un chemin, " --" est requis ou git refuse de continuer.
Il est actuellement implémenté comme:

• (1) si un argument est rev, alors il ne doit pas exister dans worktree
• (2) sinon, il doit exister dans worktree
• (3) sinon, " --" est requis.

Ces règles fonctionnent pour les chemins littéraux, mais lorsqu'une spécification de chemin non littérale est impliquée, elle oblige presque toujours l'utilisateur à ajouter " --" car elle échoue (2) et (1) est vraiment rarement respectée (prenez " *.c" par exemple, (1) est satisfaite s'il existe une référence nommée " *.c").

Ce correctif modifie un peu les règles en considérant toute *spécification de chemin de caractères génériques valide ( ) "existe dans le worktree".
Les règles deviennent:

• (1) si un argument est un rev, alors il doit exister dans worktree ou ne pas être une spécification de chemin générique valide.
• (2) sinon, il existe dans worktree ou est un caractère générique pathspec
• (3) sinon, " --" est requis.

Avec les nouvelles règles, " --" n'est plus nécessaire la plupart du temps lorsque le caractère générique pathspec est impliqué.

Avec Git 2.26 (Q1 2020), la logique de désambiguïsation pour distinguer les révisions et les pathspec a été modifiée de sorte que les caractères spéciaux glob échappés de barre oblique inverse ne comptent pas dans la règle "les caractères génériques sont des pathspec".

Voir commit 39e21c6 (25 janvier 2020) de Jeff King ( peff) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 341f8a6 , 12 fév 2020)}

verify_filename(): gérer les barres obliques inverses dans la règle "les caractères génériques sont des chemins d'accès"

^{Signalé par: David Burström
Signé par: Jeff King}

Commit 28fcc0b71a ( pathspec: évitez d'avoir besoin de " --" lorsque le caractère générique est utilisé, 2015-05-02) autorisé:

git rev-parse '*.c'

sans le double tiret.

Mais la règle qu'il utilise pour vérifier les caractères génériques recherche en fait n'importe quelle spéciale de glob.
C'est trop libéral, car cela signifie qu'un modèle qui ne fait aucune correspondance générique, comme " a\b", sera considéré comme une spécification de chemin.

Si vous avez un tel fichier sur le disque, c'est probablement ce que vous vouliez.
Mais si vous ne le faites pas, les résultats sont déroutants: plutôt que de dire " there's no such path a\b", nous l'accepterons tranquillement comme une pathspec qui ne correspond probablement à rien (ou du moins pas à ce que vous vouliez).
De même, la recherche du chemin " a\*b" n'élargit pas du tout la recherche; il ne trouverait qu'une seule entrée, " a*b".

Cette validation commute la règle pour qu'elle ne se déclenche que lorsque les métacaractères glob élargissent la recherche, ce qui signifie que ces deux cas signaleront désormais une erreur (vous pouvez toujours lever l'ambiguïté en utilisant " --", bien sûr; nous resserrons simplement l'heuristique DWIM).

( DWIM: Faites ce que je veux dire )

Notez que nous n'avons pas du tout testé la fonctionnalité d'origine dans 28fcc0b71a .
Ce correctif teste donc non seulement ces cas d'angle, mais ajoute également un test de régression pour le comportement existant.