git-fast-import - En ligne dans le Cloud

PROGRAMME:

Nom

git-fast-import - Backend pour les importateurs de données Git rapides

SYNOPSIS

frontal | jet importation rapide [choix]

DESCRIPTION

Ce programme n'est généralement pas ce que l'utilisateur final souhaite exécuter directement. La plupart des utilisateurs finaux veulent
d'utiliser l'un des programmes frontend existants, qui analyse un type spécifique de fichier étranger
source et alimente le contenu qui y est stocké jet importation rapide.

fast-import lit un flux mixte de commandes/données à partir d'une entrée standard et en écrit un ou plusieurs
packfiles directement dans le référentiel actuel. Lorsque EOF est reçu sur l'entrée standard,
l'importation rapide écrit les références de branche et de balise mises à jour, mettant à jour complètement le référentiel actuel
avec les données nouvellement importées.

Le backend d'importation rapide lui-même peut importer dans un référentiel vide (celui qui a déjà
été initialisé par jet init) ou mettre à jour de manière incrémentielle un référentiel rempli existant.
La prise en charge ou non des importations supplémentaires à partir d'une source étrangère particulière dépend
sur le programme frontal utilisé.

OPTIONS

--Obliger
Forcer la mise à jour des branches existantes modifiées, même si cela entraînerait des commits
perdu (car le nouveau commit ne contient pas l'ancien commit).

--silencieux
Désactivez toutes les sorties non fatales, rendant l'importation rapide silencieuse lorsqu'elle réussit. Cette
L'option désactive la sortie affichée par --stats.

--Statistiques
Afficher quelques statistiques de base sur les objets créés par fast-import, les fichiers pack
ils ont été stockés et la mémoire utilisée par fast-import au cours de cette exécution. Affichage
cette sortie est actuellement la sortie par défaut, mais peut être désactivée avec --quiet.

Options en Parties avant
--cat-blob-fd=
Écrire les réponses aux requêtes get-mark, cat-blob et ls dans le descripteur de fichier
au lieu de stdout. Permet de séparer la sortie de progression destinée à l'utilisateur final
d'une autre sortie.

--date-format=
Spécifiez le type de dates que le frontend fournira pour l'importation rapide au sein de l'auteur,
commandes committer et tagger. Voir « Formats de date » ci-dessous pour plus de détails sur les
les formats sont pris en charge, ainsi que leur syntaxe.

--terminé
Terminer avec une erreur s'il n'y a pas de commande done à la fin du flux. Cette option
peut être utile pour détecter les erreurs qui provoquent l'arrêt du frontend avant lui
a commencé à écrire un flux.

Implantations of Les marques Fichiers
--export-marques=
Vide la table des marques internes vers une fois terminé. Les marques sont écrites une par ligne
comme :markid SHA-1. Les frontends peuvent utiliser ce fichier pour valider les importations une fois qu'elles ont été
terminé, ou pour enregistrer le tableau des repères sur les exécutions incrémentielles. Comme est seulement
ouvert et tronqué au point de contrôle (ou à l'achèvement), le même chemin peut également être en toute sécurité
donné à --import-marks.

--import-marques=
Avant de traiter une entrée, chargez les marques spécifiées dans . Le fichier d'entrée doit
existent, doivent être lisibles et doivent utiliser le même format que celui produit par --export-marks.
Plusieurs options peuvent être fournies pour importer plus d'un ensemble de marques. Si une marque est
défini à des valeurs différentes, le dernier fichier l'emporte.

--import-marks-if-exists=
Comme --import-marks mais au lieu d'émettre une erreur, saute silencieusement le fichier si c'est le cas
n'existe pas.

--[pas-]marques-relatives
Après avoir spécifié --relative-marks les chemins spécifiés avec --import-marks= et
--export-marks= sont relatifs à un répertoire interne dans le référentiel actuel. Dans
git-fast-import cela signifie que les chemins sont relatifs au .git/info/fast-import
annuaire. Cependant, d'autres importateurs peuvent utiliser un emplacement différent.

Les marques relatives et non relatives peuvent être combinées par entrelacement --(no-)-relative-marks
avec les options --(import|export)-marks=.

Performance ainsi que Compression Tuning
--active-branches=
Nombre maximum de branches à maintenir actives à la fois. Voir « Utilisation de la mémoire » ci-dessous
pour les détails. La valeur par défaut est 5.

--big-file-threshold=
Taille maximale d'un blob pour lequel l'importation rapide tentera de créer un delta, exprimée
en octets. La valeur par défaut est de 512 m (512 Mio). Certains importateurs peuvent souhaiter réduire ce
systèmes à mémoire limitée.

--profondeur=
Profondeur delta maximale, pour la deltification des taches et des arbres. La valeur par défaut est 10.

--export-pack-edges=
Après avoir créé un packfile, imprimez une ligne de données sur liste le nom de fichier du
packfile et le dernier commit sur chaque branche qui a été écrit dans ce packfile. Cette
des informations peuvent être utiles après l'importation de projets dont l'ensemble total d'objets dépasse le
Limite de fichier pack de 4 Gio, car ces commits peuvent être utilisés comme points de périphérie lors des appels à jet
pack-objets.

--max-pack-size=
Taille maximale de chaque fichier pack de sortie. La valeur par défaut est illimitée.

PERFORMANCE

La conception de l'import rapide lui permet d'importer des projets volumineux dans un minimum de mémoire
temps d'utilisation et de traitement. En supposant que le frontend soit capable de suivre l'importation rapide et
alimentez-le en flux constant de données, importez les temps pour les projets ayant plus de 10 ans d'histoire
et contenant plus de 100,000 1 commits individuels sont généralement terminés en seulement 2 à XNUMX heures sur
matériel assez modeste (~ 2,000 XNUMX USD).

La plupart des goulots d'étranglement semblent être liés à l'accès aux données de sources étrangères (la source ne peut tout simplement pas
extraire les révisions assez rapidement) ou les E/S du disque (l'importation rapide écrit aussi vite que le disque le fera
prendre les données). Les importations s'exécuteront plus rapidement si les données source sont stockées sur un autre lecteur
que le référentiel Git de destination (en raison de moins de conflits d'E/S).

PREMIUM COST

Une interface typique pour l'importation rapide a tendance à peser environ 200 lignes de
Code Perl/Python/Ruby. La plupart des développeurs ont pu créer des importateurs fonctionnels en seulement
quelques heures, même s'il s'agit de leur première exposition à l'importation rapide, et parfois
même à Git. C'est une situation idéale, étant donné que la plupart des outils de conversion sont jetables
(à utiliser une fois et ne jamais regarder en arrière).

PARALLÈLE FONCTIONNEMENT

Comme jet pousser or jet rapporter, les importations gérées par fast-import peuvent être exécutées en toute sécurité avec
appels parallèles git repack -a -d ou git gc, ou toute autre opération Git (y compris jet
pruneau, car les objets en vrac ne sont jamais utilisés par l'importation rapide).

fast-import ne verrouille pas les références de branche ou de balise qu'il importe activement. Après le
import, lors de sa phase de mise à jour de la ref, fast-import teste chaque ref de branche existante pour vérifier
la mise à jour sera une mise à jour rapide (le commit stocké dans la ref est contenu dans le
nouvel historique du commit à écrire). Si la mise à jour n'est pas une mise à jour rapide,
fast-import ignorera la mise à jour de cette référence et affichera à la place un message d'avertissement. importation rapide
tentera toujours de mettre à jour toutes les références de branche et ne s'arrêtera pas au premier échec.

Les mises à jour de branche peuvent être forcées avec --force, mais il est recommandé de ne l'utiliser que sur
un référentiel par ailleurs silencieux. L'utilisation de --force n'est pas nécessaire pour une importation initiale dans
un référentiel vide.

SUPPORT DISCUSSION

fast-import suit un ensemble de branches en mémoire. Toute branche peut être créée ou modifiée sur
à tout moment pendant le processus d'importation en envoyant une commande commit sur le flux d'entrée. Cette
la conception permet à un programme frontal de traiter un nombre illimité de branches
simultanément, en générant des commits dans l'ordre où ils sont disponibles à partir des données source.
Il simplifie également considérablement les programmes frontend.

fast-import n'utilise ni ne modifie le répertoire de travail actuel, ni aucun fichier qu'il contient.
(Il met cependant à jour le référentiel Git actuel, tel que référencé par GIT_DIR.) Par conséquent
une interface d'importation peut utiliser le répertoire de travail à ses propres fins, telles que l'extraction
révisions de fichiers à partir de la source étrangère. Cette méconnaissance du répertoire de travail a également
permet à l'import rapide de s'exécuter très rapidement, car il n'a pas besoin d'effectuer de fichier coûteux
les opérations de mise à jour lors du basculement entre les branches.

CONTRIBUTION Format

À l'exception des données de fichier brutes (que Git n'interprète pas), l'entrée d'importation rapide
le format est basé sur du texte (ASCII). Ce format basé sur du texte simplifie le développement et le débogage
des programmes frontaux, en particulier lorsqu'un langage de niveau supérieur tel que Perl, Python ou Ruby
est en train d'être utilisé.

fast-import est très strict sur son entrée. Où nous disons SP ci-dessous, nous voulons dire exactement UN
espacer. De même LF signifie un (et un seul) saut de ligne et HT un (et un seul) horizontal
languette. La fourniture de caractères d'espacement supplémentaires entraînera des résultats inattendus, tels que
les noms de branche ou les noms de fichiers avec des espaces de début ou de fin dans leur nom, ou au début
l'arrêt de l'importation rapide lorsqu'il rencontre une entrée inattendue.

Discussions Commentaires
Pour faciliter le débogage des frontends, fast-import ignore toute ligne commençant par # (ASCII
livre/dièse) jusqu'à et y compris la ligne se terminant LF. Une ligne de commentaire peut contenir n'importe quel
séquence d'octets qui ne contient pas de LF et peut donc être utilisée pour inclure n'importe quel
informations de débogage détaillées qui peuvent être spécifiques au frontend et utiles lorsque
inspecter un flux de données d'importation rapide.

Date Formats
Les formats de date suivants sont pris en charge. Une interface doit sélectionner le format qu'elle utilisera
pour cet import en passant le nom du format dans --date-format= option de ligne de commande.

brut
Il s'agit du format natif de Git et SP . C'est aussi l'import rapide
format par défaut, si --date-format n'a pas été spécifié.

L'heure de l'événement est indiquée par comme le nombre de secondes depuis l'UNIX
epoch (minuit, 1er janvier 1970, UTC) et est écrit sous forme d'entier décimal ASCII.

Le décalage local est spécifié par comme un décalage positif ou négatif par rapport à l'UTC.
Par exemple, EST (qui a 5 heures de retard sur UTC) serait exprimé en par "-0500"
tandis que l'UTC est "+0000". Le décalage local n'affecte pas ; il est utilisé uniquement comme un
conseils pour aider les routines de formatage à afficher l'horodatage.

Si le décalage local n'est pas disponible dans le matériel source, utilisez "+0000", ou le plus
décalage local commun. Par exemple, de nombreuses organisations ont un référentiel CVS qui a
n'ont été consultés que par des utilisateurs situés au même endroit et dans le même fuseau horaire.
Dans ce cas, un décalage raisonnable par rapport à l'UTC pourrait être supposé.

Contrairement au format rfc2822, ce format est très strict. Toute variation dans le formatage
provoquera le rejet de la valeur par fast-import.

rfc2822
Il s'agit du format de courrier électronique standard tel que décrit par la RFC 2822.

Un exemple de valeur est « Tue Feb 6 11:22:18 2007 -0500 ». L'analyseur Git est précis, mais un
peu du côté clément. C'est le même analyseur utilisé par jet am lors de l'application des patchs
reçu par e-mail.

Certaines chaînes mal formées peuvent être acceptées comme dates valides. Dans certains de ces cas, Git
toujours en mesure d'obtenir la date correcte à partir de la chaîne mal formée. Il y a aussi
certains types de chaînes malformées que Git analysera mal, et pourtant considérera valides.
Les chaînes gravement mal formées seront rejetées.

Contrairement au format brut ci-dessus, les informations de fuseau horaire/de décalage UTC contenues dans un RFC
La chaîne de date 2822 est utilisée pour ajuster la valeur de la date à UTC avant le stockage. Par conséquent
il est important que ces informations soient aussi précises que possible.

Si le matériel source utilise des dates de style RFC 2822, le frontend doit permettre une importation rapide
gérer l'analyse et la conversion (plutôt que d'essayer de le faire lui-même) en tant que Git
parser a été bien testé dans la nature.

Les frontends devraient préférer le format brut si le matériel source utilise déjà UNIX-epoch
format, peut être amené à donner des dates dans ce format, ou son format est facilement
convertible en elle, car il n'y a pas d'ambiguïté dans l'analyse.

maintenant
Utilisez toujours l'heure et le fuseau horaire actuels. Le littéral now doit toujours être fourni pour
.

Il s'agit d'un format jouet. L'heure et le fuseau horaire actuels de ce système sont toujours copiés
dans la chaîne d'identité au moment de sa création par fast-import. Il n'y a pas
moyen de spécifier une heure ou un fuseau horaire différent.

Ce format particulier est fourni car il est court à mettre en œuvre et peut être utile à un
processus qui veut créer un nouveau commit maintenant, sans avoir besoin d'utiliser un
répertoire ou jet index-mise à jour.

Si des commandes distinctes d'auteur et de commiteur sont utilisées dans un commit, les horodatages peuvent ne pas
correspond, car l'horloge système sera interrogée deux fois (une fois pour chaque commande). Le seul moyen
pour s'assurer que les informations d'identité de l'auteur et de l'auteur ont le même horodatage
est d'omettre l'auteur (donc copier du committer) ou d'utiliser un format de date autre que
maintenant.

Commandes
fast-import accepte plusieurs commandes pour mettre à jour le référentiel actuel et contrôler le
processus d'importation en cours. Une discussion plus détaillée (avec des exemples) de chaque commande suit
plus tard.

commettre
Crée une nouvelle branche ou met à jour une branche existante en créant un nouveau commit et
mettre à jour la branche pour pointer vers le commit nouvellement créé.

Étiquette
Crée un objet de balise annoté à partir d'une validation ou d'une branche existante. Étiquettes légères
ne sont pas pris en charge par cette commande, car ils ne sont pas recommandés pour l'enregistrement
moments significatifs dans le temps.

réinitialiser
Réinitialiser une branche existante (ou une nouvelle branche) à une révision spécifique. Cette commande doit
être utilisé pour changer une branche en une révision spécifique sans faire de validation dessus.

goutte
Convertissez les données de fichier brutes en un blob, pour une utilisation future dans une commande de validation. Cette commande est
facultatif et n'est pas nécessaire pour effectuer une importation.

point de contrôle
Force fast-import à fermer le packfile actuel, générer sa somme de contrôle SHA-1 unique
et index, et démarrez un nouveau packfile. Cette commande est facultative et n'est pas nécessaire pour
effectuer une importation.

Les Progrès
L'importation rapide renvoie l'intégralité de la ligne sur sa propre sortie standard. Cette commande est
facultatif et n'est pas nécessaire pour effectuer une importation.

fait
Marque la fin du flux. Cette commande est facultative à moins que la fonction done n'ait été
demandé à l'aide de l'option de ligne de commande --done ou de la commande feature done.

obtenir une note
Provoque l'import rapide pour imprimer le SHA-1 correspondant à une marque dans le descripteur de fichier
défini avec --cat-blob-fd, ou stdout si non spécifié.

chat-blob
Provoque une importation rapide pour imprimer un blob dans chat-fichier --grouper format au descripteur de fichier
défini avec --cat-blob-fd ou stdout si non spécifié.

ls
Provoque fast-import pour imprimer une ligne décrivant une entrée de répertoire dans ls-arbre format à
le descripteur de fichier défini avec --cat-blob-fd ou stdout s'il n'est pas spécifié.

caractéristique
Activez la fonctionnalité spécifiée. Cela nécessite que fast-import prenne en charge le
fonction, et s'interrompt si ce n'est pas le cas.

option
Spécifiez l'une des options répertoriées sous OPTIONS qui ne modifient pas la sémantique du flux en
répondre aux besoins du frontend. Cette commande est facultative et n'est pas nécessaire pour effectuer une
importer.

commettre
Créez ou mettez à jour une branche avec un nouveau commit, en enregistrant un changement logique dans le projet.

'engager' SP LF
marque?
(« auteur » (SP ) ? SP LT GT SP LF) ?
« commissaire » (SP ) ? SP LT GT SP LF
données
('de' SP LF) ?
('fusionner' SP LF) ?
(filemodify | filelete | filecopy | filerename | fileleteall | notemodify)*
LF ?

où est le nom de la branche sur laquelle effectuer le commit. Généralement, les noms de branche sont
préfixé avec refs/heads/ dans Git, donc l'importation du symbole de branche CVS RELENG-1_0 utiliserait
refs/heads/RELENG-1_0 pour la valeur de . La valeur de doit être un nom de référence valide
dans Git. Comme LF n'est pas valide dans un nom de référence Git, aucune syntaxe de guillemet ou d'échappement n'est prise en charge
ici.

Une commande de marquage peut éventuellement apparaître, demandant une importation rapide pour enregistrer une référence au
commit nouvellement créé pour une utilisation future par le frontend (voir ci-dessous pour le format). C'est très
commun pour les frontends de marquer chaque commit qu'ils créent, permettant ainsi à la future branche
création à partir de n'importe quel commit importé.

La commande de données suivant le commiter doit fournir le message de validation (voir ci-dessous pour les données
syntaxe de commande). Pour importer un message de validation vide, utilisez des données de longueur 0. Valider des messages
sont de forme libre et ne sont pas interprétés par Git. Actuellement, ils doivent être encodés en UTF-8, car
fast-import ne permet pas de spécifier d'autres encodages.

Zéro ou plus de modification de fichier, suppression de fichier, copie de fichier, renommage de fichier, suppression de fichier tout et modification de note
des commandes peuvent être incluses pour mettre à jour le contenu de la branche avant de créer le
s'engager. Ces commandes peuvent être fournies dans n'importe quel ordre. Cependant, il est recommandé qu'un
la commande filedeleteall précède toutes les commandes filemodify, filecopy, filerename et notemodify
dans le même commit, comme fileeleteall nettoie la branche (voir ci-dessous).

Le LF après la commande est facultatif (il était auparavant obligatoire).

auteur
Une commande d'auteur peut éventuellement apparaître, si les informations sur l'auteur peuvent différer de
les informations du commiteur. Si l'auteur est omis, l'importation rapide sera automatiquement
utiliser les informations du commiter pour la partie auteur du commit. Voir ci-dessous pour un
description des champs dans author, car ils sont identiques à committer.

committer
La commande committer indique qui a effectué ce commit et quand il l'a fait.

Ici est le nom d'affichage de la personne (par exemple "Com M Itter") et est
l'adresse e-mail de la personne ("[email protected]»). LT et GT sont le littéral inférieur à
(\x3c) et les symboles supérieur à (\x3e). Ceux-ci sont nécessaires pour délimiter l'e-mail
l'adresse des autres champs de la ligne. Noter que et sont de forme libre
et peut contenir n'importe quelle séquence d'octets, à l'exception de LT, GT et LF. est généralement UTF-8
codé.

L'heure du changement est spécifiée par en utilisant le format de date qui a été sélectionné
par le --date-format= option de ligne de commande. Voir « Formats de date » ci-dessus pour l'ensemble
des formats pris en charge et leur syntaxe.

de
La commande from est utilisée pour spécifier le commit à partir duquel initialiser cette branche. Cette
révision sera le premier ancêtre du nouveau commit. L'état de l'arbre construit à
ce commit commencera par l'état du commit from, et sera modifié par le
modifications de contenu dans ce commit.

L'omission de la commande from dans le premier commit d'une nouvelle branche entraînera une importation rapide
pour créer ce commit sans ancêtre. Cela a tendance à n'être souhaité que pour le premier
engagement d'un projet. Si l'interface crée tous les fichiers à partir de zéro lors de la création d'un nouveau
branche, une commande de fusion peut être utilisée à la place de from pour démarrer le commit avec une valeur vide
arbre. L'omission de la commande from sur les branches existantes est généralement souhaitée, car la
le commit actuel sur cette branche est automatiquement supposé être le premier ancêtre du
nouveau commit.

Comme LF n'est pas valide dans un nom de référence Git ou une expression SHA-1, pas de guillemets ni de syntaxe d'échappement
est pris en charge dans .

Ici est l'un des éléments suivants :

· Le nom d'une branche existante déjà dans la table de branche interne de fast-import. Si
fast-import ne connaît pas le nom, il est traité comme une expression SHA-1.

· Une référence de marque, : , où est le numéro de la marque.

La raison pour laquelle fast-import utilise : pour désigner une référence de marque, ce caractère n'est pas
legal dans un nom de branche Git. Le leader : permet de distinguer facilement les
mark 42 (:42) et la branche 42 (42 ou refs/heads/42), ou un SHA-1 abrégé
qui s'est avéré être composé uniquement de chiffres en base 10.

Les marques doivent être déclarées (via la marque) avant de pouvoir être utilisées.

· Un commit SHA-40 complet de 1 octets ou abrégé en hexadécimal.

· Toute expression Git SHA-1 valide qui se résout en un commit. Voir « SPÉCIFICATION
RÉVISIONS » dans gitrévisions(7) pour plus de détails.

· La valeur nulle spéciale SHA-1 (40 zéros) spécifie que la branche doit être supprimée.

Le cas particulier du redémarrage d'un import incrémental à partir de la valeur courante de la branche
doit s'écrire comme :

de refs/heads/branch^0

Le suffixe ^0 est nécessaire car l'importation rapide ne permet pas à une branche de démarrer à partir de
elle-même, et la branche est créée en mémoire avant même que la commande from ne soit lue à partir de
l'entrée. L'ajout de ^0 forcera fast-import à résoudre le commit via Git's
bibliothèque d'analyse de révision, plutôt que sa table de branche interne, chargeant ainsi dans
la valeur existante de la succursale.

fusionner
Comprend un commit d'ancêtre supplémentaire. Le lien d'ascendance supplémentaire ne change pas
la façon dont l'état de l'arbre est construit à ce commit. Si la commande from est omise lorsque
création d'une nouvelle branche, le premier commit de fusion sera le premier ancêtre du
commit actuel, et la branche démarrera sans fichier. Un nombre illimité de
les commandes de fusion par commit sont autorisées par fast-import, établissant ainsi un n-way
fusionner.

Ici est l'une des expressions de spécification de validation également acceptées par from
(voir au dessus).

fichiermodifier
Inclus dans une commande commit pour ajouter un nouveau fichier ou modifier le contenu d'un fichier existant
déposer. Cette commande a deux manières différentes de spécifier le contenu du fichier.

Format de données externes
Le contenu des données du fichier a déjà été fourni par une commande blob précédente. Les
le frontend a juste besoin de le connecter.

'M' SP SP SP LF

Ici généralement doit être soit une référence de marque (: ) fixé par un a priori
blob, ou un SHA-40 complet de 1 octets d'un objet blob Git existant. Si est
040000` puis doit être le SHA-40 complet de 1 octets d'une arborescence Git existante
objet ou une référence de marque définie avec --import-marks.

Format de données en ligne
Le contenu des données du fichier n'a pas encore été fourni. Le front-end veut
fournissez-le dans le cadre de cette commande de modification.

'M' SP SP "en ligne" SP LF
données

Voir ci-dessous pour une description détaillée de la commande de données.

Dans les deux formats est le type d'entrée de fichier, spécifié en octal. Git seulement
prend en charge les modes suivants :

· 100644 ou 644 : Un fichier normal (non exécutable). La majorité des fichiers dans la plupart des
les projets utilisent ce mode. En cas de doute, c'est ce que vous voulez.

· 100755 ou 755 : Un fichier normal, mais exécutable.

· 120000 : Un lien symbolique, le contenu du fichier sera la cible du lien.

· 160000 : Un gitlink, SHA-1 de l'objet fait référence à un commit dans un autre référentiel.
Les liens Git ne peuvent être spécifiés que par SHA ou via une marque de validation. Ils ont l'habitude de
implémenter des sous-modules.

· 040000 : Un sous-répertoire. Les sous-répertoires ne peuvent être spécifiés que par SHA ou via un
marque d'arbre définie avec --import-marks.

Dans les deux formats est le chemin complet du fichier à ajouter (si ce n'est déjà fait
existant) ou modifié (si déjà existant).

UNE chaîne doit utiliser des séparateurs de répertoire de style UNIX (barre oblique /), peut
contenir un octet autre que LF et ne doit pas commencer par un guillemet double (").

Un chemin peut utiliser des guillemets de style C ; ceci est accepté dans tous les cas et obligatoire si
le nom de fichier commence par des guillemets doubles ou contient LF. Dans les citations de style C, l'intégralité
le nom doit être entouré de guillemets doubles et de tout LF, barre oblique inverse ou guillemet double
les caractères doivent être échappés en les faisant précéder d'une barre oblique inverse (par exemple, "chemin/avec\n, \\
et \" dedans").

La valeur de doit être sous forme canonique. C'est-à-dire qu'il ne faut pas :

· contenir un composant de répertoire vide (par exemple foo//bar est invalide),

· terminer par un séparateur de répertoire (par exemple foo/ est invalide),

· commencer par un séparateur de répertoire (par exemple /foo n'est pas valide),

· contiennent le composant spécial . ou .. (par exemple foo/./bar et foo/../bar sont
invalide).

La racine de l'arbre peut être représentée par une chaîne vide comme .

Il est recommandé de toujours être encodé en UTF-8.

fichiersupprimer
Inclus dans une commande commit pour supprimer un fichier ou supprimer récursivement un
répertoire de la branche. Si la suppression du fichier ou du répertoire rend son répertoire parent
vide, le répertoire parent sera également automatiquement supprimé. Cela remonte le
tree jusqu'à ce que le premier répertoire non vide ou la racine soit atteint.

'D' SP LF

ici est le chemin complet du fichier ou du sous-répertoire à supprimer du
branche. Voir filemodify ci-dessus pour une description détaillée de .

copie de fichier
Copie récursivement un fichier ou un sous-répertoire existant vers un emplacement différent dans le
branche. Le fichier ou le répertoire existant doit exister. Si la destination existe, elle sera
être complètement remplacé par le contenu copié de la source.

'C' SP SP LF

ici le premier est l'emplacement source et le deuxième est la destination.
Voir filemodify ci-dessus pour une description détaillée de ce que peut ressembler. Pour utiliser un
chemin source qui contient SP le chemin doit être cité.

Une commande de copie de fichier prend effet immédiatement. Une fois l'emplacement source copié
à la destination, aucune commande future appliquée à l'emplacement source n'aura d'impact
la destination de la copie.

renommer le fichier
Renomme un fichier ou un sous-répertoire existant à un emplacement différent dans la branche.
Le fichier ou le répertoire existant doit exister. Si la destination existe, elle sera
remplacé par le répertoire source.

'R' SP SP LF

ici le premier est l'emplacement source et le deuxième est la destination.
Voir filemodify ci-dessus pour une description détaillée de ce que peut ressembler. Pour utiliser un
chemin source qui contient SP le chemin doit être cité.

Une commande de changement de nom de fichier prend effet immédiatement. Une fois que l'emplacement source a été
renommé en destination, toutes les commandes futures appliquées à l'emplacement source seront
créer de nouveaux fichiers là-bas et n'affecte pas la destination du changement de nom.

Notez qu'un nom de fichier est identique à une copie de fichier suivie d'une suppression de fichier du
emplacement de la source. L'utilisation de filerename présente un léger avantage en termes de performances, mais le
l'avantage est si petit qu'il ne vaut jamais la peine d'essayer de convertir une paire supprimer/ajouter dans
le matériel source dans un renommage pour une importation rapide. Cette commande de renommage est fournie
juste pour simplifier les frontends qui ont déjà des informations de renommage et ne veulent pas s'embêter
en le décomposant en une copie de fichier suivie d'une suppression de fichier.

déposésupprimertout
Inclus dans une commande commit pour supprimer tous les fichiers (et aussi tous les répertoires) du
branche. Cette commande réinitialise la structure de la branche interne pour qu'elle n'ait aucun fichier,
permettant à l'interface d'ajouter par la suite tous les fichiers intéressants à partir de zéro.

'supprimer tout' LF

Cette commande est extrêmement utile si le frontend ne sait pas (ou ne se soucie pas de
savoir) quels fichiers sont actuellement sur la branche, et ne peuvent donc pas générer le bon
commandes filelete pour mettre à jour le contenu.

Émettre un fileleteall suivi des commandes filemodify nécessaires pour définir le bon
contenu produira les mêmes résultats que d'envoyer uniquement le fichier nécessaire modifier et
commandes de suppression de fichier. L'approche defileleteall peut cependant nécessiter une importation rapide pour utiliser
un peu plus de mémoire par branche active (moins de 1 Mio même pour la plupart des grands projets) ;
donc les frontends qui peuvent facilement obtenir uniquement les chemins affectés pour un commit sont
encouragé à le faire.

notemodifier
Inclus dans un commit commande pour ajouter une nouvelle note annotant un
ou modifier le contenu de cette annotation. En interne, il est similaire à filemodify 100644 sur
path (peut-être divisé en sous-répertoires). Il n'est pas conseillé d'utiliser d'autres
commandes pour écrire dans le arborescence sauf fichiereleteall pour supprimer tous les existants
notes dans cet arbre. Cette commande a deux manières différentes de spécifier le contenu de
la note.

Format de données externes
Le contenu des données de la note était déjà fourni par une commande blob précédente. Les
le frontend a juste besoin de le connecter au commit qui doit être annoté.

'N' SP SP LF

Ici peut être soit une référence de marque (: ) défini par un blob antérieur
commande ou un SHA-40 complet de 1 octets d'un objet blob Git existant.

Format de données en ligne
Le contenu des données de la note n'a pas encore été fourni. Le front-end veut
fournissez-le dans le cadre de cette commande de modification.

'N' SP 'en ligne' SP LF
données

Voir ci-dessous pour une description détaillée de la commande de données.

Dans les deux formats est l'une des expressions de spécification de validation également
accepté par de (voir ci-dessus).

marque
Prend en charge l'importation rapide pour enregistrer une référence à l'objet actuel, permettant à l'interface
pour rappeler cet objet à un instant futur, sans connaître son SHA-1. Ici le
l'objet actuel est la commande de création d'objet dans laquelle la commande de marquage apparaît. Cela peut être
commit, tag et blob, mais commit est l'utilisation la plus courante.

'marque' SP ':' LF

où est le numéro attribué par le frontend à cette marque. La valeur de est
exprimé sous forme d'entier décimal ASCII. La valeur 0 est réservée et ne peut pas être utilisée comme
marque. Seules les valeurs supérieures ou égales à 1 peuvent être utilisées comme notes.

De nouvelles marques sont créées automatiquement. Les marques existantes peuvent être déplacées vers un autre objet simplement
en réutilisant le même dans une autre commande de marque.

Étiquette
Crée une balise annotée faisant référence à un commit spécifique. Pour créer de la légèreté
balises (non annotées) voir la commande reset ci-dessous.

'tag' SP LF
'de' SP LF
'tagger' (SP ) ? SP LT GT SP LF
données

où est le nom de la balise à créer.

Les noms de balises sont automatiquement préfixés par refs/tags/ lorsqu'ils sont stockés dans Git, ce qui permet d'importer le
Le symbole de branche CVS RELENG-1_0-FINAL utiliserait uniquement RELENG-1_0-FINAL pour , et
fast-import écrira la référence correspondante sous la forme refs/tags/RELENG-1_0-FINAL.

La valeur de doit être un refname valide dans Git et peut donc contenir forward
barres obliques. Comme LF n'est pas valide dans un nom de référence Git, aucune syntaxe de guillemet ou d'échappement n'est prise en charge
ici.

La commande from est la même que dans la commande commit ; voir ci-dessus pour les détails.

La commande tagger utilise le même format que committer dans commit ; voir à nouveau ci-dessus pour
détails.

La commande de données qui suit le tagueur doit fournir le message de tag annoté (voir ci-dessous pour
syntaxe de la commande de données). Pour importer un message de balise vide, utilisez des données de longueur 0. Les messages de balise sont
forme libre et ne sont pas interprétés par Git. Actuellement, ils doivent être encodés en UTF-8, car
fast-import ne permet pas de spécifier d'autres encodages.

La signature de balises annotées lors de l'importation à partir de fast-import n'est pas prise en charge. Essayer
inclure votre propre signature PGP/GPG n'est pas recommandé, car le frontend ne le fait pas (facilement)
avoir accès à l'ensemble complet des octets qui entrent normalement dans une telle signature. Si
la signature est requise, créez des balises légères à partir de l'importation rapide avec réinitialisation, puis
créer les versions annotées de ces balises hors ligne avec la norme jet Étiquette processus.

réinitialiser
Crée (ou recrée) la branche nommée, éventuellement à partir d'une révision spécifique. Les
La commande reset permet à une interface d'émettre une nouvelle commande from pour une branche existante, ou de
créer une nouvelle branche à partir d'un commit existant sans créer de nouveau commit.

'réinitialiser' SP LF
('de' SP LF) ?
LF ?

Pour une description détaillée de et voir ci-dessus sous commit et from.

Le LF après la commande est facultatif (il était auparavant obligatoire).

La commande reset peut également être utilisée pour créer des balises légères (non annotées). Pour
Exemple:

réinitialiser les références/balises/938
à partir de :938

créerait la balise légère refs/tags/938 faisant référence à n'importe quelle marque de validation : 938
les références.

goutte
Demande l'écriture d'une révision de fichier dans le packfile. La révision n'est liée à aucun
s'engager; cette connexion doit être formée dans une commande de validation ultérieure en référençant le
blob à travers une marque attribuée.

'blob' LF
marque?
données

La commande mark est facultative ici car certains frontends ont choisi de générer le Git SHA-1
pour le blob par eux-mêmes, et le nourrir directement pour s'engager. C'est généralement plus de travail
que cela ne vaut cependant, car les marques sont peu coûteuses à stocker et faciles à utiliser.

données
Fournit des données brutes (à utiliser comme contenu blob/fichier, messages de validation ou balise annotée
messages) pour une importation rapide. Les données peuvent être fournies en utilisant un nombre exact d'octets ou délimitées par
une ligne de terminaison. Les vrais frontends destinés aux conversions de qualité de production devraient
utilisez toujours le format exact du nombre d'octets, car il est plus robuste et plus performant. Les
le format délimité est principalement destiné à tester l'importation rapide.

Les lignes de commentaires apparaissant dans le une partie des commandes de données sont toujours considérées comme faisant partie
du corps des données et ne sont donc jamais ignorés par fast-import. Cela le rend sûr
pour importer tout contenu de fichier/message dont les lignes peuvent commencer par #.

Format exact du nombre d'octets
Le frontend doit spécifier le nombre d'octets de données.

SP « données » LF
LF ?

où est le nombre exact d'octets apparaissant dans . La valeur de
est exprimé sous forme d'entier décimal ASCII. Le LF de chaque côté de est
non inclus dans et ne seront pas inclus dans les données importées.

Le LF après est facultatif (auparavant obligatoire) mais recommandé. Toujours
y compris cela facilite le débogage d'un flux d'importation rapide car la commande suivante est toujours
commence dans la colonne 0 de la ligne suivante, même si ne s'est pas terminé par un LF.

Format délimité
Une chaîne de séparation est utilisée pour marquer la fin des données. fast-import calculera le
longueur en recherchant le délimiteur. Ce format est principalement utile pour tester et
n'est pas recommandé pour les données réelles.

'données' SP '<<' LF
LF
LF
LF ?

où est la chaîne de délimiteur choisie. La chaîne ne doit pas apparaître sur un
ligne par elle-même à l'intérieur , car sinon l'importation rapide pensera que les données se terminent plus tôt
qu'il ne le fait vraiment. Le LF est immédiatement à la traîne fait partie de . C'est un
des limitations du format délimité, il est impossible de fournir un morceau de données
qui n'a pas de LF comme dernier octet.

Le LF après LF est facultatif (il était auparavant obligatoire).

point de contrôle
Force fast-import à fermer le packfile actuel, à en démarrer un nouveau et à tout enregistrer
références, balises et marques de branche actuelles.

'point de contrôle' LF
LF ?

Notez que fast-import change automatiquement de packfiles lorsque le packfile actuel atteint
--max-pack-size, ou 4 Gio, selon la limite la plus petite. Lors d'un changement automatique de packfile
fast-import ne met pas à jour les références de branche, les balises ou les marques.

Comme un point de contrôle peut nécessiter une quantité importante de temps CPU et d'E/S disque (pour calculer le
somme de contrôle globale du pack SHA-1, générer le fichier d'index correspondant et mettre à jour les références)
l'exécution d'une seule commande de point de contrôle peut facilement prendre plusieurs minutes.

Les frontends peuvent choisir d'émettre des points de contrôle lors d'importations extrêmement volumineuses et de longue durée,
ou lorsqu'ils doivent autoriser un autre processus Git à accéder à une branche. Cependant étant donné qu'un 30
Le référentiel GiB Subversion peut être chargé dans Git via une importation rapide en environ 3 heures,
des points de contrôle explicites peuvent ne pas être nécessaires.

Le LF après la commande est facultatif (il était auparavant obligatoire).

Les Progrès
Provoque l'import rapide pour imprimer la ligne de progression entière sans modification à sa sortie standard
canal (descripteur de fichier 1) lorsque la commande est traitée à partir du flux d'entrée. Les
sinon, la commande n'a aucun impact sur l'importation en cours ou sur l'une des commandes internes de fast-import.
Etat.

SP « progrès » LF
LF ?

Les une partie de la commande peut contenir n'importe quelle séquence d'octets qui ne contient pas LF.
Le LF après la commande est facultatif. Les appelants peuvent souhaiter traiter la sortie via un
outil tel que sed pour supprimer la première partie de la ligne, par exemple :

frontal | git fast-import | sed 's/^progress //'

Placer une commande de progression immédiatement après un point de contrôle informera le lecteur lorsque le
point de contrôle a été terminé et il peut accéder en toute sécurité aux références que l'importation rapide a mis à jour.

obtenir une note
Provoque l'import rapide pour imprimer le SHA-1 correspondant à une marque vers la sortie standard ou vers le fichier
descripteur préalablement arrangé avec l'argument --cat-blob-fd. La commande a sinon
aucun impact sur l'importation actuelle ; son but est de récupérer les SHA-1 qui s'engagent plus tard
voudront peut-être faire référence dans leurs messages de validation.

'get-mark' SP ':' LF

Cette commande peut être utilisée n'importe où dans le flux où les commentaires sont acceptés. En particulier,
la commande get-mark peut être utilisée au milieu d'un commit mais pas au milieu d'une donnée
commander.

Voir « Réponses aux commandes » ci-dessous pour plus de détails sur la façon de lire cette sortie en toute sécurité.

chat-blob
Provoque l'import rapide pour imprimer un blob dans un descripteur de fichier préalablement organisé avec le
--cat-blob-fd argument. Sinon, la commande n'a aucun impact sur l'import en cours ; son
le but principal est de récupérer des blobs qui peuvent être dans la mémoire de fast-import mais pas accessibles
du référentiel cible.

'chat-blob' SP LF

Les peut être soit une référence de marque (: ) défini précédemment ou un entier de 40 octets
SHA-1 d'un blob Git, préexistant ou prêt à être écrit.

La sortie utilise le même format que git cat-file --batch :

SP "tache" SP LF
LF

Cette commande peut être utilisée n'importe où dans le flux où les commentaires sont acceptés. En particulier,
la commande cat-blob peut être utilisée au milieu d'un commit mais pas au milieu d'une donnée
commander.

Voir « Réponses aux commandes » ci-dessous pour plus de détails sur la façon de lire cette sortie en toute sécurité.

ls
Imprime des informations sur l'objet à un chemin d'accès à un descripteur de fichier précédemment organisé
avec l'argument --cat-blob-fd. Cela permet d'imprimer un blob à partir du commit actif (avec
cat-blob) ou en copiant un blob ou un arbre d'un commit précédent pour l'utiliser dans le commit actuel
(avec modification de fichier).

La commande ls peut être utilisée n'importe où dans le flux où les commentaires sont acceptés, y compris
au milieu d'un commit.

Lecture à partir du commit actif
Ce formulaire ne peut être utilisé qu'au milieu d'un commit. Le chemin nomme une entrée de répertoire
dans le commit actif de fast-import. Le chemin doit être indiqué dans ce cas.

'ls' SP LF

Lecture à partir d'un arbre nommé
Les peut être une référence de marque ( : ) ou le SHA-40 complet de 1 octets d'un Git
tag, commit ou tree object, préexistant ou en attente d'être écrit. Le chemin est
par rapport au niveau supérieur de l'arbre nommé par .

'ls' SP SP LF

Voir filemodify ci-dessus pour une description détaillée de .

La sortie utilise le même format que git ls-tree -- :

SP ('blob' | 'tree' | 'commit') SP HT LF

Les représente l'objet blob, tree ou commit à et peut être utilisé dans
plus tard obtenir une note, chat-blob, fichiermodifierou ls les commandes.

S'il n'y a pas de fichier ou de sous-arborescence à ce chemin, jet importation rapide rapportera à la place

SP manquant LF

Voir « Réponses aux commandes » ci-dessous pour plus de détails sur la façon de lire cette sortie en toute sécurité.

caractéristique
Exiger que fast-import prenne en charge la fonctionnalité spécifiée, ou abandonner si ce n'est pas le cas.

SP « fonctionnalité » ('=' ) ? LF

Les une partie de la commande peut être l'un des éléments suivants :

format de date, marques d'exportation, marques relatives, aucune marque relative, force
Faites comme si l'option de ligne de commande correspondante précédée d'un -- a été transmis
la ligne de commande (voir OPTIONS, ci-dessus).

marques d'importation, marques d'importation si elles existent
Comme --import-marks sauf à deux égards : d'abord, une seule "feature import-marks" ou
La commande "feature import-marks-if-exists" est autorisée par flux ; deuxièmement, un
L'option de ligne de commande --import-marks= ou --import-marks-if-exists remplace l'une de ces options
commandes « fonctionnalité » dans le flux ; troisièmement, "caractéristique import-marks-if-exists" comme un
L'option de ligne de commande correspondante ignore silencieusement un fichier inexistant.

obtenir-marque, chat-blob, ls
Exiger que le backend prenne en charge le obtenir une note, chat-blobou ls commande respectivement.
Les versions de fast-import ne prenant pas en charge la commande spécifiée se fermeront avec un message
l'indiquant ainsi. Cela permet à l'erreur d'importation de sortir tôt avec un message clair, plutôt que
perdre du temps sur la première partie d'une importation avant que la commande non prise en charge ne soit
détecté.

note
Exiger que le backend prenne en charge le notemodifier (N) sous-commande au commettre commander.
Les versions d'import rapide ne prenant pas en charge les notes sortiront avec un message l'indiquant.

fait
Erreur si le flux se termine sans fait commander. Sans cette fonctionnalité, les erreurs
faire en sorte que le frontend se termine brusquement à un point pratique du flux peut aller
non détecté. Cela peut se produire, par exemple, si un frontal d'importation meurt en cours d'opération
sans émettre SIGTERM ou SIGKILL sur son instance subordonnée git fast-import.

option
Traite l'option spécifiée afin que git fast-import se comporte d'une manière qui convient
les besoins du frontend. Notez que les options spécifiées par le frontend sont remplacées par n'importe quel
options que l'utilisateur peut spécifier pour git fast-import lui-même.

'option' SP LF

Les une partie de la commande peut contenir n'importe laquelle des options répertoriées dans les OPTIONS
section qui ne change pas la sémantique d'importation, sans le premier -- et est traité dans le
de la même façon.

Les commandes d'option doivent être les premières commandes sur l'entrée (sans compter les commandes de fonctionnalité),
donner une commande d'option après toute commande non optionnelle est une erreur.

Les options de ligne de commande suivantes modifient la sémantique d'importation et peuvent donc ne pas être transmises
en option :

· format de date

· marques d'importation

· marques d'exportation

· chat-blob-fd

· Obliger

fait
Si la fonction done n'est pas utilisée, traitée comme si EOF était lu. Cela peut être utilisé pour dire
importation rapide pour terminer plus tôt.

Si l'option de ligne de commande --done ou la commande feature done est en cours d'utilisation, la commande done est
obligatoire et marque la fin du flux.

RÉPONSES À COMMANDES

Les nouveaux objets écrits par fast-import ne sont pas disponibles immédiatement. Importation la plus rapide
les commandes n'ont aucun effet visible jusqu'au prochain point de contrôle (ou achèvement). Le front-end
peut envoyer des commandes pour remplir le tube d'entrée de fast-import sans se soucier de la rapidité avec laquelle elles
prendra effet, ce qui améliore les performances en simplifiant la planification.

Pour certaines interfaces, cependant, il est utile de pouvoir relire les données du
référentiel au fur et à mesure de sa mise à jour (par exemple, lorsque le matériel source décrit des objets
en termes de patchs à appliquer aux objets précédemment importés). Cela peut être
accompli en connectant le frontend et l'import rapide via des tuyaux bidirectionnels :

mkfifo importation-sortie rapide
l'extrémité avant
git fast-import > fast-import-output

Une interface configurée de cette manière peut utiliser les commandes progress, get-mark, ls et cat-blob pour lire
informations de l'import en cours.

Pour éviter les blocages, ces interfaces doivent consommer complètement toute sortie en attente de
progress, ls, get-mark et cat-blob avant d'effectuer des écritures sur fast-import qui pourraient
bloque.

CRASH RAPPORTS

Si fast-import est fourni une entrée invalide, il se terminera avec un état de sortie différent de zéro et
créer un rapport de plantage au niveau supérieur du référentiel Git dans lequel il importait. crash
les rapports contiennent un instantané de l'état interne de l'importation rapide ainsi que le plus récent
commandes qui mènent au crash.

Toutes les commandes récentes (y compris les commentaires de flux, les modifications de fichiers et les commandes de progression) sont
affiché dans l'historique des commandes dans le rapport d'incident, mais les données de fichier brutes et la validation
les messages sont exclus du rapport d'incident. Cette exclusion permet d'économiser de l'espace dans le rapport
et réduit la quantité de mise en mémoire tampon que l'importation rapide doit effectuer pendant l'exécution.

Après avoir écrit un rapport de crash, fast-import fermera le packfile actuel et exportera le
tableau des marques. Cela permet au développeur front-end d'inspecter l'état du référentiel et de reprendre
l'importation à partir du point où elle s'est écrasée. Les branches et balises modifiées ne sont pas mises à jour
lors d'un plantage, car l'importation ne s'est pas terminée avec succès. Informations sur les branches et les balises
peut être trouvé dans le rapport de plantage et doit être appliqué manuellement si la mise à jour est nécessaire.

Un exemple de plantage :

$ chat >dans <
# mon tout premier commit de test
valider les références/heads/master
le commissaire Shawn O. Pearce 19283 -0400
# qui est ce gars de toute façon?
données <
c'est mon engagement
EOF
M 644 en ligne .gitignore
données <
.gitignore
EOF
Bob en ligne M 777
END_OF_INPUT

$ git fast-import
fatal : Mode corrompu : M 777 bob en ligne
fast-import : vidage du rapport de plantage dans .git/fast_import_crash_8434

$ chat .git/fast_import_crash_8434
rapport d'erreur d'importation rapide :
processus d'importation rapide : 8434
processus parent : 1391
au sam 1 sept. 00:58:12 2007

fatal : Mode corrompu : M 777 bob en ligne

Commandes les plus récentes avant le crash
---------------------------------
# mon tout premier commit de test
valider les références/heads/master
le commissaire Shawn O. Pearce 19283 -0400
# qui est ce gars de toute façon?
données <
M 644 en ligne .gitignore
données <
* Bob en ligne M 777

Branche active LRU
-----------------
active_branches = 1 courant, 5 max

nom de l'horloge pos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 arbitres/têtes/maître

Branches inactives
-----------------
réfs/chefs/maître :
statut : actif chargé sale
astuce commit : 0000000000000000000000000000000000000000
vieil arbre : 0000000000000000000000000000000000000000
arbre cur : 0000000000000000000000000000000000000000
horloge de validation : 0
dernier paquet :


RAPPORT DE FIN DE CRASH

CONSEILS ET DES TRUCS

Les trucs et astuces suivants ont été collectés auprès de divers utilisateurs de fast-import, et
sont proposés ici à titre de suggestions.

Utilisez UN Marquez Pour S’ENGAGER
Lors d'une conversion de référentiel, utilisez une marque unique par commit (marque : ) et fournir
l'option --export-marks sur la ligne de commande. fast-import videra un fichier qui répertorie
chaque marque et l'objet Git SHA-1 qui lui correspond. Si le frontend peut lier le
renvoie au référentiel source, il est facile de vérifier l'exactitude et l'exhaustivité des
l'importation en comparant chaque commit Git à la révision source correspondante.

Venant d'un système tel que Perforce ou Subversion, cela devrait être assez simple, car le
La marque d'importation rapide peut également être le numéro de l'ensemble de modifications Perforce ou la révision de Subversion
.

Librement Skip Environ Branches
Ne vous embêtez pas à essayer d'optimiser le frontend pour vous en tenir à une branche à la fois pendant un
importer. Bien que cela puisse être légèrement plus rapide pour l'importation rapide, il a tendance à augmenter
considérablement la complexité du code frontend.

La branche LRU intégrée à l'importation rapide a tendance à très bien se comporter, et le coût de
l'activation d'une branche inactive est si faible que rebondir entre les branches a
pratiquement aucun impact sur les performances à l'importation.

Maniabilité Renomme
Lors de l'importation d'un fichier ou d'un répertoire renommé, supprimez simplement le(s) ancien(s) nom(s) et modifiez le
nouveau(x) nom(s) lors du commit correspondant. Git effectue une détection de renommage après coup,
plutôt qu'explicitement lors d'un commit.

Utilisez Jour Réparer Branches
Certains autres systèmes SCM permettent à l'utilisateur de créer une étiquette à partir de plusieurs fichiers qui ne proviennent pas de
le même commit/changeset. Ou pour créer des balises qui sont un sous-ensemble des fichiers disponibles dans
le référentiel.

Importer ces balises telles quelles dans Git est impossible sans faire au moins un commit qui
« corrige » les fichiers pour qu'ils correspondent au contenu de la balise. Utilisez la commande de réinitialisation de fast-import pour
réinitialiser une branche factice en dehors de votre espace de branche normal à la validation de base pour la balise,
puis validez un ou plusieurs commits de correction de fichier, et enfin balisez la branche factice.

Par exemple, puisque toutes les branches normales sont stockées sous refs/heads/ name the tag fixup
branche TAG_FIXUP. De cette façon, il est impossible pour la branche fixup utilisée par l'importateur de
avoir des conflits d'espace de noms avec de vraies branches importées de la source (le nom TAG_FIXUP
n'est pas refs/heads/TAG_FIXUP).

Lors de la validation des correctifs, envisagez d'utiliser merge pour connecter le ou les commits qui fournissent
révisions du fichier à la branche fixup. Cela permettra à des outils tels que jet blâmer traquer
à travers l'historique des commits réels et annoter correctement les fichiers sources.

Après la fin de l'importation rapide, l'interface devra faire rm .git/TAG_FIXUP pour supprimer le
branche factice.

L’ Maintenant, Remplacer Later
Dès que l'importation rapide est terminée, le référentiel Git est complètement valide et prêt à l'emploi.
En règle générale, cela ne prend que très peu de temps, même pour des projets de très grande envergure
(plus de 100,000 XNUMX commits).

Cependant, le reconditionnement du référentiel est nécessaire pour améliorer la localisation et l'accès aux données
performance. Cela peut également prendre des heures sur des projets extrêmement volumineux (surtout si -f et un
grand paramètre --window est utilisé). Étant donné que le remballage peut être exécuté en toute sécurité avec les lecteurs et
écrivains, exécutez le repack en arrière-plan et laissez-le se terminer quand il se termine. Il n'y a pas
raison d'attendre pour explorer votre nouveau projet Git !

Si vous choisissez d'attendre le reconditionnement, n'essayez pas d'exécuter des benchmarks ou des tests de performances
jusqu'à ce que le remballage soit terminé. fast-import produit des packfiles sous-optimaux qui sont simplement
jamais vu dans des situations d'utilisation réelles.

Remballage Historique Données
Si vous reconditionnez des données importées très anciennes (par exemple plus anciennes que l'année dernière), pensez à
dépenser du temps CPU supplémentaire et fournir --window=50 (ou supérieur) lorsque vous exécutez jet
Remballer. Cela prendra plus de temps, mais produira également un fichier pack plus petit. Vous n'avez qu'à
dépensez l'effort une fois, et tous ceux qui utilisent votre projet bénéficieront du plus petit
dépôt.

Comprendre Certain Progrès Mes Messages
De temps en temps, votre frontend émet un message de progression pour une importation rapide. Les
le contenu des messages est entièrement de forme libre, donc une suggestion serait de sortir le
le mois et l'année en cours chaque fois que la date de validation actuelle passe au mois suivant. Ton
les utilisateurs se sentiront mieux en sachant combien de flux de données a été traité.

FICHIER PACK OPTIMISATION

Lors de l'emballage d'un blob, l'importation rapide tente toujours de se comparer au dernier blob écrit.
À moins que cela ne soit spécifiquement organisé par le frontend, ce ne sera probablement pas un préalable
version du même fichier, donc le delta généré ne sera pas le plus petit possible. Les
Le packfile résultant sera compressé, mais ne sera pas optimal.

Frontends qui ont un accès efficace à toutes les révisions d'un seul fichier (par exemple
lire un fichier RCS/CVS ,v) peut choisir de fournir toutes les révisions de ce fichier sous forme de séquence
de commandes blob consécutives. Cela permet à l'import rapide de supprimer les différents fichiers
révisions les unes par rapport aux autres, économisant de l'espace dans le packfile final. Les marques peuvent être utilisées pour
identifier plus tard les révisions de fichiers individuels au cours d'une séquence de commandes de validation.

Le(s) packfile(s) créé(s) par fast-import n'encouragent pas de bons modèles d'accès au disque. C'est
causé par l'écriture rapide des données dans l'ordre où elles sont reçues sur l'entrée standard,
tandis que Git organise généralement les données dans les packfiles pour les rendre les plus récentes (astuce actuelle)
les données apparaissent avant les données historiques. Git regroupe également les commits, accélérant
traversée de révision à travers une meilleure localité de cache.

Pour cette raison, il est fortement recommandé aux utilisateurs de remballer le référentiel avec git
repack -a -d après la fin de l'import rapide, permettant à Git de réorganiser les packfiles pour
accès plus rapide aux données. Si les deltas de blob sont sous-optimaux (voir ci-dessus), ajoutez également le -f
option pour forcer le recalcul de tous les deltas peut réduire considérablement le packfile final
taille (30-50% plus petite peut être assez typique).

MÉMOIRE UTILISATION

Il existe un certain nombre de facteurs qui affectent la quantité de mémoire requise par l'importation rapide pour effectuer
une importation. Comme les sections critiques du noyau Git, l'importation rapide utilise ses propres allocateurs de mémoire
pour amortir les frais généraux associés à malloc. Dans la pratique, l'importation rapide a tendance à
amortir tous les frais généraux malloc à 0, en raison de son utilisation d'allocations de blocs volumineux.

/ objet
fast-import maintient une structure en mémoire pour chaque objet écrit dans cette exécution.
Sur un système 32 bits, la structure est de 32 octets, sur un système 64 bits, la structure est de 40 octets
(en raison de la plus grande taille des pointeurs). Les objets de la table ne sont pas désalloués tant que
l'importation rapide se termine. L'importation de 2 millions d'objets sur un système 32 bits nécessitera
environ 64 Mio de mémoire.

La table d'objets est en fait une table de hachage codée sur le nom de l'objet (l'unique SHA-1). Cette
la configuration du stockage permet à l'import rapide de réutiliser un objet existant ou déjà écrit
et évitez d'écrire des doublons dans le packfile de sortie. Les blobs en double sont étonnamment
courant dans une importation, généralement en raison de fusions de branches dans la source.

/ marque
Les marques sont stockées dans un tableau clairsemé, en utilisant 1 pointeur (4 octets ou 8 octets, selon
taille du pointeur) par marque. Bien que le tableau soit clairsemé, les frontends sont toujours fortement
encouragés à utiliser des notes comprises entre 1 et n, où n est le nombre total de notes requises pour
cette importation.

/ une succursale
Les succursales sont classées comme actives et inactives. L'utilisation de la mémoire des deux classes est
significativement différent.

Les branches inactives sont stockées dans une structure qui utilise 96 ou 120 octets (32 bits ou 64 bits
systèmes, respectivement), plus la longueur du nom de la branche (généralement moins de 200 octets),
par branche. fast-import traitera facilement jusqu'à 10,000 2 branches inactives en moins de XNUMX
Mio de mémoire.

Les branches actives ont la même surcharge que les branches inactives, mais contiennent également des copies de
chaque arbre qui a été récemment modifié sur cette branche. Si l'inclusion de sous-arbre n'a pas été
modifié depuis que la branche est devenue active, son contenu ne sera pas chargé en mémoire, mais
si le sous-arbre src a été modifié par un commit depuis que la branche est devenue active, alors son
le contenu sera chargé en mémoire.

Comme les branches actives stockent des métadonnées sur les fichiers contenus dans cette branche, leur
la taille du stockage en mémoire peut atteindre une taille considérable (voir ci-dessous).

fast-import déplace automatiquement les branches actives vers le statut inactif sur la base d'un simple
algorithme le moins utilisé récemment. La chaîne LRU est mise à jour à chaque commande de validation. Les
le nombre maximum de branches actives peut être augmenté ou diminué sur la ligne de commande avec
--branches-actives=.

/ infection arbre
Les arbres (ou répertoires) n'utilisent que 12 octets de mémoire en plus de la mémoire requise pour
leurs entrées (voir « par fichier actif » ci-dessous). Le coût d'un arbre est pratiquement de 0, car son
les frais généraux s'amortissent sur les entrées de fichier individuelles.

/ infection filet entrée
Les fichiers (et les pointeurs vers les sous-arbres) dans les arbres actifs nécessitent 52 ou 64 octets (32/64 bits
plates-formes) par entrée. Pour économiser de l'espace, les noms de fichiers et d'arborescences sont regroupés dans une chaîne commune
table, permettant au nom de fichier "Makefile" d'utiliser seulement 16 octets (après avoir inclus la chaîne
surcharge d'en-tête) quel que soit le nombre de fois qu'il se produit dans le projet.

La branche active LRU, lorsqu'elle est couplée avec le pool de chaînes de nom de fichier et le chargement paresseux de
sous-arbres, permet une importation rapide pour importer efficacement des projets avec plus de 2,000 XNUMX branches et
45,114 2.7+ fichiers dans une empreinte mémoire très limitée (moins de XNUMX Mio par branche active).

SIGNAUX

Envoi SIGUSR1 à la jet importation rapide le processus termine plus tôt le packfile actuel, simulant
une commande de point de contrôle. L'opérateur impatient peut utiliser cette fonction pour jeter un coup d'œil aux objets
et les références d'une importation en cours, au prix d'un temps d'exécution supplémentaire et pire
compression.

Utilisez git-fast-import en ligne en utilisant les services onworks.net