Quand le dépôt à cloner est sur la machine locale, cette option court-circuite les mécanismes de transport « spécial Git » normaux et clone le dépôt en faisant une copie de HEAD et de tout ce qu’il y a dans les répertoires objects et refs. Les fichiers sous le répertoire .git/objects/ sont liés physiquement si possible pour économiser l’espace disque.

Forcer le processus de clonage depuis un dépôt sur un système de fichier local à copier les fichiers sous le répertoire .git\objects au lieu d’utiliser des liens physiques. Ceci peut être voulu si vous souhaitez faire une copie de sauvegarde de votre dépôt.

Quand le dépôt à cloner est sur la machine locale, au lieu d’utiliser des liens physiques, créer automatiquement .git/objects/info/alternates pour partager les objets du dépôt source. Le dépôt résultant démarre sans aucun objet qui lui soit propre.

Si le <dépôt> référence est sur la machine locale, créer automatiquement .git/objects/info/alternates pour obtenir les objets depuis le <dépôt> référence. L’utilisation d’un dépôt déjà existant comme alternative nécessitera moins d’objets à copier depuis le dépôt à cloner, limitant les coûts de réseau et de stockage local. Avec l’utilisation de --reference-if-able, un répertoire inexistant est ignoré avec un message d’avertissement au lieu de faire échouer le clonage.

Emprunter les objets des dépôts référence spécifiés avec les options --reference seulement pour réduire les transferts réseau, et arrêter de les emprunter après la création d’un clone en créant les copies locales nécessaires des objets empruntés. Cette option peut aussi être utilisée lors d’un clonage local depuis un dépôt qui emprunte déjà des objets à un autre dépôt — le nouveau dépôt va emprunter des objets au même dépôt, et cette option peut être utilisée pour arrêter l’emprunt.

Mode silencieux. L’avancement n’est pas affiché sur le flux d’erreur standard.

Mode verbeux. N’agit pas sur l’affichage de l’état d’avancement sur le flux d’erreur standard.

L’état d’avancement est affiché sur la sortie d’erreur standard quand elle est attachée à un terminal, à moins que --quiet soit spécifié. Ce drapeau force l’état d’avancement même si le flux d’erreur standard n’est pas dirigé vers un terminal.

Transmettre la chaîne donnée au serveur lors d’une communication utilisant la version 2 du protocole. La chaîne donnée ne doit pas contenir de caractère NUL ou LF. La gestion par le serveur des options du serveur, y compris les options inconnues, est spécifique au serveur. Lorsque plusieurs --server-option=<option> sont donnés, ils sont tous envoyés à l’autre côté dans l’ordre indiqué sur la ligne de commande.

Aucune extraction de HEAD n’est effectuée après la fin du clonage.

Échouer si le dépôt source est un dépôt superficiel. La variable de configuration clone.rejectShallow peut être utilisée pour spécifier la valeur par défaut.

Créer un dépôt Git « nu ». Cela signifie qu’au lieu de créer <répertoire> et de placer les fichiers administratifs dans <répertoire>`/.git`, faire de <répertoire> lui-même le $GIT_DIR. Cela implique évidemment l’option --no-checkout parce qu’il n’y a nulle part où extraire l’arbre de travail. De plus, les têtes de branches distantes sont également copiées directement dans les têtes de branches locales correspondantes, sans les préfixer de refs/remotes/origin/. Lorsque cette option est utilisée, ni les branches de suivi à distance ni les variables de configuration s’y rattachant ne sont créées.

Employer une extraction clairsemée, avec seulement les fichiers dans le répertoire de plus haut niveau initialement présent. La commande git-sparse-checkout[1] peut être utilisée pour agrandir le répertoire de travail si nécessaire.

Utiliser la fonction de clonage partiel et demander que le serveur envoie un sous-ensemble d’objets accessibles selon un filtre d’objets donné. Lorsque l’on utilise --filter, le <spéc-de-filtre> fourni est utilisé pour le filtre de clonage partiel. Par exemple, --filter=blob:none filtrera tous les blobs (contenu des fichiers) jusqu’à ce que Git en ait besoin. De même, --filter=blob:limit=<taille> filtrera tous les blobs de taille au moins égale à <taille>. Pour plus de détails sur les spécifications de filtre, voir l’option --filter dans git-rev-list[1].

Applique également le filtre de clonage partiel à tous les sous-modules du dépôt. Requiert --filter et --recurse-submodules. Ceci peut être activé par défaut en définissant l’option de configuration clone.filterSubmodules.

Construire un miroir du dépôt source. Ceci implique --bare. Par rapport à --bare, --mirror fait correspondre non seulement les branches locales de la source sur les branches locales de la cible, mais également toutes les références (y compris les branches de suivi à distance, les notes, etc.) et elle définit une configuration de refspec telle que toutes ces références sont réécrites par un git remote update dans le dépôt cible.

Au lieu d’utiliser le nom de distant origin pour suivre le dépôt amont, utiliser <nom>. Remplace clone.defaultRemoteName dans la configuration.

Au lieu de pointer la HEAD nouvellement créée sur la branche pointée par la HEAD du dépôt cloné, pointer plutôt sur la branche <nom>. Dans un dépôt non-nu, c’est la branche qui sera extraite. --branch accepte aussi des étiquettes et détache alors la HEAD à ce commit dans le dépôt résultant.

Quand cette option est indiquée et que le dépôt à cloner est accédé via ssh, ceci spécifie un chemin différent de celui par défaut pour la commande lancée sur l’hôte distant.

Spécifier le répertoire depuis lequel les modèles vont être tirés ; (voir la section « RÉPERTOIRE DE MODÈLES » de git-init[1].)

Définir une variable de configuration dans le dépôt nouvellement créé ; ceci prend effet immédiatement après que le dépôt est initialisé, mais avant que l’historique distant ne soit récupéré ou qu’un fichier soit extrait. La <clé> est dans le même format qu’attendu par git-config[1] (par exemple, core.eol=true). Si des valeurs multiples sont fournies pour la même clé, chaque valeur sera écrite dans le fichier de configuration. Ceci sécurise, par exemple, l’ajout de spécificateurs de référence de récupération supplémentaires pour le dépôt distant d’origine.

Créer un clone « superficiel » avec un historique tronqué au nombre spécifié de commits. Implique --single-branch à moins que --no-single-branch ne soit fourni pour récupérer les historiques proches des sommets de toutes les branches. Pour cloner des sous-modules de manière superficielle, passer aussi --shallow-submodules.

Créer un clone superficiel avec un historique après le temps spécifié.

Créer un clone superficiel avec un historique, en excluant les commits joignables depuis une branche distante spécifiée ou une étiquette. Cette option peut être spécifiée plusieurs fois.

Cloner uniquement l’historique menant au sommet d’une seule branche, soit spécifiée par l’option --branch, soit la branche primaire sur laquelle la HEAD du distant pointe. Des récupérations subséquentes dans le dépôt résultant ne mettront à jour que la branche de suivi à distance de la branche pour laquelle cette option a été utilisée lors du clonage initial. Si la HEAD du dépôt distant ne pointait sur aucune branche quand le clonage --single-branch a été fait, aucune branche de suivi à distance n’est créée.

Ne cloner aucune étiquette et positionner remote.<distant>.tagOpt=--no-tags en configuration, de sorte que les futures opérations git pull et git fetch ne tireront aucune étiquette. Les récupérations explicites d’étiquette fonctionneront toujours (voir git-fetch[1]).

Après création du clone, initialiser et cloner les sous-modules inclus à partir du <spec-de-chemin> fourni. Si aucun =<spec-de-chemin> n’est fourni, tous les sous-modules sont initialisés et clonés. Cette option peut être spécifiée plus d’une fois pour des spécificateurs de chemins correspondant à des entrées différentes. Le clone résultant a la configuration submodule.active réglée sur le spécificateur de chemin fourni ou "." (qui signifie tous les sous-modules) si aucun spécificateur de chemin n’est fourni.

Tous les sous-modules qui sont clonés seront superficiels avec une profondeur de 1.

Tous les sous-modules clonés utiliseront l’état de la branche de suivi à distance du sous-module pour mettre à jour le sous-module, plutôt que le SHA-1 enregistré par le superprojet. Équivalent à passer --remote à git submodule update.

Au lieu de placer le dépôt clone là où il est supposé être, placer le dépôt clone dans le répertoire spécifié, puis créer un lien symbolique Git indépendant du système de fichiers. Le résultat est un dépôt Git qui est séparé de son arbre de travail.

Spécifier le format de stockage de réf donné pour le dépôt. Les valeurs valides sont :

Le nombre de sous-modules récupérés en même temps. Par défaut, l’option submodule.fetchJobs.

Le <dépôt> (éventuellement distant) depuis lequel cloner. Voir les sections URL GIT ci-dessous pour plus d’information sur la spécification de dépôts.

Le nom du nouveau répertoire dans lequel cloner. La partie « humaine » du dépôt source est utilisée si aucun <répertoire> n’est fourni explicitement (dépôt pour /chemin/vers/un/dépôt.git et toto pour hôte.xz:toto/.git). Cloner dans un répertoire existant n’est permis que si le répertoire en question est vide.

Avant de récupérer depuis le distant, récupérer un colis à partir du <uri> donné et décompresser les données dans le dépôt local. Les références dans le colis seront stockées dans l’espace de nom caché refs/bundle/*. Cette option est incompatible avec --depth, --shallow-since, et --shallow-exclude.