Quelle est la différence entre git clone --mirror et git clone --bare ?

Question

La page d'aide de git clone contient ce qui suit --mirror :

Mettre en place un miroir du dépôt distant. Cela implique que --bare .

Mais il n'entre pas dans les détails de la manière dont la --mirror est différent d'un clone --bare clone.

Answer 1

La différence est que lors de l'utilisation de --mirror , a les refs sont copiés en l'état . Cela signifie tout : branches de suivi à distance, notes, refs/originals/* (sauvegardes de filter-branch). Le repo cloné contient tout cela. Il est également configuré pour qu'une mise à jour à distance récupère tout depuis l'origine (en écrasant les refs copiés). L'idée est vraiment de créer un miroir du dépôt, d'avoir une copie totale, de sorte que vous puissiez par exemple héberger votre dépôt central à plusieurs endroits, ou le sauvegarder. Il s'agit d'une copie pure et simple du dépôt, mais d'une manière beaucoup plus élégante que celle de git.

La nouvelle la documentation dit à peu près tout ce qu'il faut savoir :

--mirror

Mettre en place un miroir du dépôt source. Cela implique --bare . Par rapport à --bare , --mirror ne se contente pas de faire correspondre les branches locales de la source aux branches locales de la cible, il fait correspondre toutes les références (y compris les branches distantes, les notes, etc.) et met en place une configuration refspec telle que toutes ces références sont écrasées par un fichier git remote update dans le référentiel cible.

Ma réponse initiale mentionnait également les différences entre un clone nu et un clone normal (non nu) - le clone non nu met en place des branches de suivi à distance, ne créant qu'une branche locale pour le HEAD tandis que le clone nu copie directement les branches.

Supposons que l'origine ait quelques branches ( master (HEAD) , next , pu y maint ), certains tags ( v1 , v2 , v3 ), certaines branches éloignées ( devA/master , devB/master ), et quelques autres références ( refs/foo/bar , refs/foo/baz qui peuvent être des notes, des cachettes, des espaces de noms d'autres développeurs, qui sait).

• git clone origin-url (non dénudé) : Vous obtiendrez toutes les étiquettes copiées, une branche locale master (HEAD) suivi d'une succursale distante origin/master et les succursales éloignées origin/next , origin/pu y origin/maint . Les branches de suivi sont configurées de telle sorte que si vous faites quelque chose comme git fetch origin ils seront recherchés comme vous l'attendez. Les branches distantes (dans le clone distant) et les autres références sont complètement ignorées.

• git clone --bare origin-url : Vous obtiendrez toutes les étiquettes copiées, les branches locales master (HEAD) , next , pu y maint pas de branches de suivi à distance. En d'autres termes, toutes les branches sont copiées telles quelles, et elles sont configurées de manière totalement indépendante, sans aucune attente de récupération. Toutes les branches distantes (dans la branche distante clonée) et les autres références sont complètement ignorées.

• git clone --mirror origin-url : Tous ces refs seront copiés tels quels. Vous obtiendrez tous les tags, les branches locales master (HEAD) , next , pu y maint , succursales à distance devA/master y devB/master autres références refs/foo/bar y refs/foo/baz . Tout est exactement comme dans la télécommande clonée. Le suivi à distance est configuré de telle sorte que si vous exécutez la commande git remote update toutes les refs seront écrasées à partir de l'origine, comme si vous veniez de supprimer le miroir et de le recloner. Comme l'indique la documentation à l'origine, il s'agit d'un miroir. Il est censé être une copie fonctionnellement identique, interchangeable avec l'original.

Answer 2

$ git clone --mirror $URL

est un raccourci pour

$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror=fetch origin $URL)

(Copié directement de aquí )

C'est ce que dit la page de manuel actuelle :

Par rapport à --bare , --mirror ne se contente pas de faire correspondre les branches locales de la source aux branches locales de la cible, il fait correspondre toutes les références (y compris les branches distantes, les notes, etc.) et met en place une configuration refspec telle que toutes ces références sont écrasées par un fichier git remote update dans le référentiel cible.

Answer 3

J'ajoute une image, je montre config différence entre miroir et nu. La gauche est nue, la droite est un miroir. Vous l'aurez compris, le fichier de configuration de mirror contient les éléments suivants fetch ce qui signifie que vous pouvez la mettre à jour, en git remote update o git fetch --all

Answer 4

Mes tests avec git-2.0.0 aujourd'hui indiquent que l'option --mirror ne copie pas les hooks, le fichier de configuration, le fichier de description, le fichier info/exclude, et au moins dans mon cas de test quelques refs (que je ne comprends pas.) Je ne dirais pas que c'est une "copie fonctionnellement identique, interchangeable avec l'original".

-bash-3.2$ git --version
git version 2.0.0
-bash-3.2$ git clone --mirror /git/hooks
Cloning into bare repository 'hooks.git'...
done.

-bash-3.2$ diff --brief -r /git/hooks.git hooks.git
Files /git/hooks.git/config and hooks.git/config differ
Files /git/hooks.git/description and hooks.git/description differ
...
Only in hooks.git/hooks: applypatch-msg.sample
...
Only in /git/hooks.git/hooks: post-receive
...
Files /git/hooks.git/info/exclude and hooks.git/info/exclude differ
...
Files /git/hooks.git/packed-refs and hooks.git/packed-refs differ
Only in /git/hooks.git/refs/heads: fake_branch
Only in /git/hooks.git/refs/heads: master
Only in /git/hooks.git/refs: meta

Answer 5

Une explication nuancée tirée de la documentation GitHub sur les Duplication d'un référentiel :

Comme pour un clone nu, un clone miroir inclut toutes les branches et étiquettes distantes, mais toutes les références locales seront écrasées à chaque fois que vous récupérerez le dépôt, de sorte qu'il sera toujours identique au dépôt original.