Insérer des déclarations de progrès tous les <n>objets, à afficher par git fast-import lors de l’importation.

Spécifier comment traiter les étiquettes signées. Puisque toute transformation après l’exportation peut changer les noms des étiquettes (ce qui peut également se produire lors de l’exclusion des révisions), les signatures ne correspondront pas.

Spécifier comment traiter les étiquettes dont l’objet étiqueté est filtré. Comme les révisions et les fichiers à exporter peuvent être limités par le chemin d’accès, les objets étiquetés peuvent être complètement filtrés.

Effectuer une détection de déplacement et/ou de copie, comme décrit dans la page de manuel git-diff[1], et l’utiliser pour générer des commandes de renommage et de copie dans le journal généré.

Décharge la table interne des marques dans un <fichier>, une fois terminé. Les marques sont écrites une par ligne comme :markid SHA-1. Seules les marques des révisions sont écrites ; les marques des blobs sont ignorées. Des moteurs peuvent utiliser ce fichier pour valider les importations après qu’elles aient été complétées, ou pour sauvegarder la table des marques à travers des exécutions incrémentales. Comme <fichier> n’est ouvert et tronqué qu’à la fin de l’opération, le même chemin peut aussi être donné sans risque à --import-marks. Le fichier ne sera pas écrit si aucun nouvel objet n’a été marqué/exporté.

Avant de traiter toute entrée, charger les marques spécifiées dans <fichier> ;. Le fichier d’entrée doit exister, doit être lisible, et doit utiliser le même format que celui produit par --export-marks.

En plus de nommer les blobs et les commits avec des identifiants de marque, vous pouvez aussi nommer les étiquettes. Ceci est utile en conjonction avec --export-marks et --import-marks, et est également utile (et nécessaire) pour l’exportation de étiquettes imbriquées. Cela ne nuit pas aux autres cas et serait la valeur par défaut, mais beaucoup de frontends d’import rapide ne sont pas préparés à accepter les étiquettes comprenant des identifiants de marque.

Certains anciens dépôts ont des étiquettes sans étiqueteur. Le protocole d’importation rapide était assez strict à ce sujet, et ne le permettait pas. Il faut donc simuler un étiqueteur pour pouvoir importer rapidement la sortie.

Démarrer le flux avec une strophe feature done et le terminer avec une commande done.

Ignorer la sortie des objets blob et faire plutôt référence aux blobs via leur hachage SHA-1 original. Ceci est utile pour réécrire la structure du répertoire ou l’historique d’un dépôt sans toucher au contenu des fichiers individuels. Notez que le flux résultant ne peut être utilisé que par un dépôt qui contient déjà les objets nécessaires.

Cette option fera en sorte que fast-export émette une directive "deleteall" pour chaque commit suivi d’une liste complète de tous les fichiers du commit (par opposition à la liste des fichiers qui sont différents du premier parent du commit).

Anonymiser le contenu du dépôt tout en conservant la forme de l’historique et de l’arbre stocké. Voir la section ANONYMISATION ci-dessous.

Convertir le jeton <depuis> en <vers> dans la sortie anonymisée. Si <vers> est omis, convertir <depuis> en lui-même (c’est-à-dire, ne pa l’anonymiser). Voir la section sur ANONYMISATION ci-dessous.

Par défaut, l’exécution d’une commande telle que git fast-export master~5..master n’inclura pas le commit master~5 et fera que master~4 n’aura plus master~5 comme parent (bien que l’ancien master~4 et le nouveau master~4 auront tous les mêmes fichiers). Utilisez --reference-excluded-parents pour que le flux fasse plutôt référence aux commits dans la plage exclue de l’historique par leur sha1sum. Notez que le flux résultant ne peut être utilisé que par un dépôt qui contient déjà les commits parents nécessaires.

Ajouter une directive supplémentaire à la sortie pour les commits et les blobs, original-oid <SHA1SUM>. Bien que de telles directives seront probablement ignorées par les importateurs tels que git-fast-import, elles peuvent être utiles pour les filtres intermédiaires (par exemple pour réécrire les messages de commit qui font référence à des commits plus anciens, ou pour dépouiller les blobs par id).

Spécifier comment gérer l’en-tête encoding dans les objets commit. En demandant abort (« abandonner » qui est la valeur par défaut), ce programme mourra lorsqu’il rencontrera un tel objet commit. Avec yes, le message de livraison sera ré-encodé en UTF-8. Avec no, l’encodage original sera préservé.

Appliquer la refspec spécifiée à chaque ref exportée. Plusieurs d’entre elles peuvent être spécifiées.

Une liste d’arguments, acceptable pour git rev-parse et git rev-list, qui spécifie les objets et références spécifiques à exporter. Par exemple, master~10..master provoque l’exportation de la référence master actuelle avec tous les objets ajoutés depuis le commit de son 10ème ancêtre et (à moins que l’option --reference-excluded-parents soit spécifiée) tous les fichiers communs à master~9 et master~10.