Écrire dans des paires de fichiers (.pack et .idx), en utilisant <nom-de-base> pour déterminer le nom du fichier créé. Lorsque cette option est utilisée, les deux fichiers d’une paire sont écrits dans les fichiers <nom-de-base>-<SHA1>.{pack,idx}. <SHA-1> est une empreinte basée sur le contenu du paquet est écrit à la sortie standard de la commande.

Écrire le contenu du paquet (ce qui aurait été écrit dans le fichier .pack) à la sortie standard.

Lire les arguments de révision de l’entrée standard, au lieu des noms d’objets individuels. Les arguments de révision sont traités de la même manière que git rev-list avec le drapeau --objects utilise ses arguments commit pour construire la liste des objets qu’il produit. Les objets de la liste résultante sont empaquetés. En plus des révisions, les lignes --not ou --shallow <SHA-1> sont également acceptées.

Cela implique --revs. Lors du traitement de la liste des arguments de révision lus à partir de l’entrée standard, limiter les objets empaquetés à ceux qui ne sont pas déjà empaquetés.

Cela implique --revs. En plus de la liste des arguments de révision lus à partir de l’entrée standard, prétendre que toutes les réfs sous refs/ sont spécifiées pour être incluses.

Inclure les étiquettes annotées non demandées si l’objet qu’elles références a été inclus dans le fichier paquet. Cela peut être utile pour envoyer de nouvelles étiquettes aux clients Git natifs.

Lire les noms de base des fichiers paquets (par exemple, pack-1234abcd.pack) depuis l’entrée standard, au lieu des arguments des noms d’objets ou de révision. Le paquet résultant contient tous les objets listés dans les paquets inclus (ceux qui ne commencent pas par ^), excluant les objets énumérés dans les paquets exclus (commençant par ^).

Empaquette les objets inaccessibles dans un paquet séparé "déchet", dénoté par l’existence d’un fichier .mtimes. Habituellement utilisé par git repack --cruft. Les appelants fournissent une liste de noms de paquets et indiquent quels paquets resteront dans le dépôt, ainsi que quels paquets seront supprimés (indiqués par le préfixe -). Le contenu du paquet déchet sont tous des objets non contenus dans les paquets survivants qui n’ont pas dépassé la période de grâce (voir --cruft-expiration ci-dessous), ou qui ont dépassé la période de grâce, mais sont accessibles à partir d’un autre objet qui n’a pas survécu.

Si spécifié, les objets sont éliminés du paquet de déchet s’ils ont un mtime plus âgé que <approxi-date>. Si des objets non spécifiés (et avec --cruft), aucun objet n’est pas éliminé.

Ces deux options affectent la façon dont les objets contenus dans le paquet sont stockés à l’aide de la compression delta. Les objets sont d’abord triés en interne par type, taille et optionnellement par noms et comparés aux autres objets dans --window pour voir si l’utilisation de compression de delta permet d’économiser de l’espace. --depth limite la profondeur maximale du delta ; la rendre trop profonde affecte la performance du côté du dépaqueteur, parce que les données de delta doivent être appliquées autant de fois pour arriver à l’objet nécessaire.

Cette option fournit une limite supplémentaire par dessus --window ; la taille de la fenêtre s’étendra dynamiquement vers le bas afin de ne pas prendre plus que <n> octets en mémoire. Ceci est utile dans les dépôts avec un mélange de grands et petits objets afin de ne pas manquer de mémoire avec une grande fenêtre, mais encore être en mesure de profiter de la grande fenêtre pour les petits objets. La taille peut être suffixée par "k", "m", ou "g". --window-memory=0 rend l’utilisation de la mémoire illimitée. La valeur par défaut est tirée de la variable de configuration pack.windowMemory.

Dans des scénarios inhabituels, il se peut que vous ne puissiez pas créer des fichiers plus grands qu’une certaine taille sur votre système de fichiers, et cette option peut être utilisée pour dire à la commande de diviser le fichier de sortie en plusieurs paquets indépendants, chacun pas plus grand que la taille donnée. La taille peut être suffixée avec "k", "m", ou "g". La taille minimale autorisée est limitée à 1 MiB. La valeur par défaut est illimitée, sauf si la variable config pack.packSizeLimit est définie. Notez que cette option peut entraîner un dépôt plus gros et plus lent ; voir la discussion dans pack.packSizeLimit.

Ce drapeau fait ignorer un objet déjà dans un paquet local qui a un fichier .keep, même si il aurait été empaqueté par ailleurs.

Ce drapeau fait ignorer un objet déjà dans le paquet donné, même s’il aurait été empaqueté par ailleurs. nom-de-paquet est le nom du fichier paquet sans répertoire (par exemple pack-123.pack). L’option peut être spécifiée plusieurs fois pour garder plusieurs paquets.

Cette option fait qu’un objet déjà dans un paquet est ignoré même s’il aurait autrement été empaqueté.

Cette option fait qu’un objet emprunté à un magasin d’objets alternatif est ignoré même s’il aurait autrement été empaqueté.

Créer une archive empaquetée uniquement si elle contiendrait au moins un objet.

L’état d’avancement est affiché sur la sortie d’erreur standard quand elle est attachée à un terminal, à moins que -q 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.

Lorsque --stdout est spécifié, le rapport de progression est affiché pendant les phases de comptage d’objets et de compression, mais il est inhibé pendant la phase d’écriture. La raison en est que dans certains cas, le flux de sortie est directement lié à une autre commande qui peut souhaiter afficher son propre état d’avancement pendant qu’elle traite les données du paquet entrant. Ce drapeau est comme --progress sauf qu’il force le rapport de progression pour la phase d’écriture même si --stdout est utilisé.

C’est utilisé pour impliquer --all-progress lorsque l’affichage de la progression est activé. Contrairement à --all-progress, ce drapeau ne force pas l’affichage de la progression par lui-même.

Ce drapeau permet à la commande de ne pas signaler sa progression sur le flux d’erreur standard.

Lors de la création d’une archive empaquetée dans un dépôt qui possède déjà des paquets, la commande réutilise les deltas existants. Cela donne parfois un paquet légèrement sous-optimal. Cette option demande à la commande de ne pas réutiliser les deltas existants mais de les calculer depuis le début.

Ce drapeau indique à la commande de ne pas réutiliser les données d’objet existantes, y compris l’objet non déltifié, forçant la recompression de tout. Cela implique --no-reuse-delta. Utile seulement dans le cas obscur où l’exécution en gros d’un niveau de compression différent sur les données emballées est souhaitée.

Spécifie le niveau de compression pour les données nouvellement compressées dans le paquet généré. Si ce n’est pas spécifié, le niveau de compression des paquets est déterminé en premier par pack.compression, puis par core.compression, et par défaut à -1, la valeur par défaut de zlib, si non defini. Ajoutez --no-reuse-object si vous voulez forcer un niveau de compression uniforme sur toutes les données, peu importe la source.

Activer l’algorithme "sparse" pour déterminer quels objets inclure dans le paquet, lorsqu’il est combiné avec l’option "--revs". Cet algorithme ne parcourt que les arbres qui apparaissent dans les chemins qui introduisent de nouveaux objets. Cela peut avoir d’importants avantages de performance lors du calcul d’un paquet pour envoyer une petite modification. Cependant, il est possible que des objets supplémentaires soient ajoutés au fichier de paquet si les commits inclus contiennent certains types de renommages directs. Si cette option n’est pas incluse, elle prend par défaut la valeur de pack.useSparse, ce qui est vrai sauf indication contraire.

Créer un paquet "fin" en omettant les objets communs entre un expéditeur et un récepteur afin de réduire le transfert sur le réseau. Cette option n’a de sens qu’avec --stdout.

Optimiser un paquet qui sera fourni à un client avec un dépôt superficiel. Cette option, combinée avec --thin, peut générer un paquet plus petit au prix de quelques lenteurs.

Une archive empaquetée peut exprimer l’objet de base d’un delta soit comme un nom d’objet de 20 octets, soit comme un décalage dans le flux, mais les anciennes versions de Git ne comprennent pas ce dernier. Par défaut, git pack-objects n’utilise que le premier format pour une meilleure compatibilité. Cette option permet à la commande d’utiliser le second format pour la compacité. Selon la longueur moyenne de la chaîne de delta, cette option réduit typiquement le fichier paquet résultant de 3 à 5 pour cent.

Spécifie le nombre de fils d’exécution à démarrer lors de la recherche de meilleures correspondances de delta. Cela exige que pack-object soit compilé avec pthreads sinon cette option est ignorée avec un avertissement. Ceci est destiné à réduire le temps d’empaquetage sur les machines multiprocesseurs. La quantité requise de mémoire pour la fenêtre de recherche de delta est cependant multipliée par le nombre de fils. La spécification de 0 provoquera l’auto-détection par Git du nombre de CPU et la définition du nombre de fils en conséquence.

Ceci est destiné à être utilisée uniquement par la suite de tests. Permet de forcer la version de l’index de paquet généré, et de forcer les entrées d’index 64 bits sur les objets situés avant le décalage donné.

Avec cette option, les parents qui sont cachés par des greffes sont néanmoins empaquetées.

Omet certains objets (généralement des blobs) du fichier paquet résultant. Voir git-rev-list[1] pour les formes valides de <spéc-de-filtre>.

Désactive tout argument --filter= précédent.

Une option de débogage pour aider au développement futur de "clones partiels". Cette option spécifie comment les objets manquants sont traités.

Omettre les objets dont on sait qu’ils se trouvent dans le distant prometteur. (Cette option a pour but de n’opérer que sur les objets créés localement, afin que lors du réempaquetage, on maintienne toujours une distinction entre les objets créés localement [sans .promisor] et les objets du distant prometteur [avec .promisor].) Ceci est utilisé avec le clone partiel.

Les objets inatteignables depuis les références dans les paquets nommés avec l’option --unpacked= sont ajoutés au paquet résultant, en plus des objets atteignables qui ne sont pas dans les paquets marqués par des fichiers *.keep. Cela implique --revs.

Empaqueter les objets seuls inaccessibles (et leurs homologues seuls enlevés). Cela implique --revs.

Garder les objets inaccessibles sous forme libre. Cela implique --revs.

Restreindre les correspondances de delta basées sur des "îlots". Voir ÎLOTS DE DELTA ci-dessous.

Lors de la compression delta, Git regroupe les objets qui peuvent être similaires en se basant sur des heuristiques utilisant le chemin vers cet objet. Bien que le regroupement d’objets par correspondance de chemin exacte soit bon pour les chemins avec de nombreuses versions, il y a des avantages à trouver des paires delta sur différents chemins complets. Git collecte les objets par type, puis par un « hachage de nom » du chemin, puis par taille, dans l’espoir de regrouper des objets qui se compresseront bien ensemble.

Effectuer la compression en organisant d’abord les objets par chemin, puis une seconde passe qui compresse sur les chemins comme d’habitude. Cela peut améliorer la compression delta, notamment en présence de noms de fichiers qui provoquent des collisions dans l’algorithme de hachage de nom par défaut de Git.