Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.43.1 → 2.47.0 no changes
- 2.43.0 11/20/23
- 2.37.1 → 2.42.3 no changes
- 2.37.0 06/27/22
- 2.35.1 → 2.36.6 no changes
- 2.35.0 01/24/22
- 2.33.1 → 2.34.8 no changes
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.29.1 → 2.30.9 no changes
- 2.29.0 10/19/20
- 2.27.1 → 2.28.1 no changes
- 2.27.0 06/01/20
- 2.23.1 → 2.26.3 no changes
- 2.23.0 08/16/19
- 2.21.1 → 2.22.5 no changes
- 2.21.0 02/24/19
- 2.20.1 → 2.20.5 no changes
- 2.20.0 12/09/18
- 2.18.1 → 2.19.6 no changes
- 2.18.0 06/21/18
- 2.17.1 → 2.17.6 no changes
- 2.17.0 04/02/18
- 2.16.6 12/06/19
- 2.15.4 no changes
- 2.14.6 12/06/19
- 2.10.5 → 2.13.7 no changes
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.5.6 → 2.7.6 no changes
- 2.4.12 05/05/17
- 2.3.10 09/28/15
- 2.1.4 → 2.2.3 no changes
- 2.0.5 12/17/14
SYNOPSIS
git pack-objects [-q | --progress | --all-progress] [--all-progress-implied] [--no-reuse-delta] [--delta-base-offset] [--non-empty] [--local] [--incremental] [--window=<n>] [--depth=<n>] [--revs [--unpacked | --all]] [--keep-pack=<nom-de-paquet>] [--cruft] [--cruft-expiration=<temps>] [--stdout [--filter=<filter-spec>] | <nom-de-base>] [--shallow] [--keep-true-parents] [--[no-]sparse] < <list-d-objests>
DESCRIPTION
Lit la liste des objets de l’entrĂ©e standard, et Ă©crit une ou plusieurs archives empaquetĂ©es avec le nom de base spĂ©cifiĂ© sur le disque, ou une archive empaquetĂ©e Ă la sortie standard.
Une archive empaquetĂ©e est un moyen efficace de transfĂ©rer un ensemble d’objets entre deux dĂ©pĂ´ts ainsi qu’un format d’archive efficace d’accès. Dans une archive empaquetĂ©e, un objet est soit stockĂ© en entier compressĂ©, soit comme une diffĂ©rence d’un autre objet. Ce dernier est souvent appelĂ© delta.
Le format d’archive empaquetĂ© (.pack) est conçu pour ĂŞtre auto-contenu afin qu’il puisse ĂŞtre dĂ©paquetĂ© sans autre information. Par consĂ©quent, chaque objet dont dĂ©pend un delta doit ĂŞtre prĂ©sent dans le paquet.
Un fichier d’index de paquet (.idx) est gĂ©nĂ©rĂ© pour un accès rapide et alĂ©atoire aux objets dans le pack. Placer Ă la fois le fichier index (.idx) et l’archive empaquetĂ©e (.pack) dans le sous-rĂ©pertoire /pack de $GIT_OBJECT_DIRECTORY (ou l’un des rĂ©pertoires sur $GIT_ALTERNATE_OBJECT_DIRECTORIES) permet Git de lire depuis l’archive empaquetĂ©e.
La commande git unpack-objects peut lire l’archive empaquetĂ©e et dĂ©velopper les objets contenus dans le paquet en format "un fichier - un objet" ; c’est gĂ©nĂ©ralement fait par les commandes smart-pull lorsqu’un paquet est crĂ©Ă© Ă la volĂ©e pour un transport rĂ©seau efficace par leurs pairs.
OPTIONS
- nom-de-base
-
É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.
- --stdout
-
Écrire le contenu du paquet (ce qui aurait été écrit dans le fichier .pack) à la sortie standard.
- --revs
-
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 argumentscommit
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. - --unpacked
-
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. - --all
-
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 sousrefs/
sont spécifiées pour être incluses. - --include-tag
-
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.
- --stdin-packs
-
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^
).Incompatible avec
--revs
, ou options qui impliquent--revs
(comme--all
), Ă l’exception de--unpacked
, qui est compatible. - --cruft
-
Empaquette les objets inaccessibles dans un paquet sĂ©parĂ© "dĂ©chet", dĂ©notĂ© par l’existence d’un fichier
.mtimes
. Habituellement utilisé pargit 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.Lorsque l’entrĂ©e Ă©numère un paquet contenant tous les objets accessibles (et Ă©numère tous les autres paquets en attente de suppression), le paquet dĂ©chet correspondant contiendra tous les objets inaccessibles (avec mtime plus rĂ©cent que le
--cruft-expiration
) ainsi que tous les objets inaccessibles dont le mtime est plus âgé que le--cruft-expiration
, mais qui sont accessibles Ă partir d’un objet inaccessible dont le mtime est plus rĂ©cent que--cruft-expiration
.Incompatible avec
--unpack-unreachable
,--keep-unreachable
,--pack-loose-unreachable
,--stdin-packs
, ainsi que toutes les autres options qui impliquent--revs
. - --cruft-expiration=<approxi-date>
-
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Ă©. - --window=<n>
- --depth=<n>
-
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.
La valeur par défaut pour --window est 10 et --depth est 50. La profondeur maximale est de 4095.
- --window-memory=<n>
-
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 configurationpack.windowMemory
. - --max-pack-size=<n>
-
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 danspack.packSizeLimit
. - --honor-pack-keep
-
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.
- --keep-pack=<nom-de-paquet>
-
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 exemplepack-123.pack
). L’option peut ĂŞtre spĂ©cifiĂ©e plusieurs fois pour garder plusieurs paquets. - --incremental
-
This flag causes an object already in a pack to be ignored even if it would have otherwise been packed.
- --local
-
This flag causes an object that is borrowed from an alternate object store to be ignored even if it would have otherwise been packed.
- --non-empty
-
Only create a packed archive if it would contain at least one object.
- --progress
-
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.
- --all-progress
-
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Ă©.
- --all-progress-implied
-
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.
- -q
-
Ce drapeau permet Ă la commande de ne pas signaler sa progression sur le flux d’erreur standard.
- --no-reuse-delta
-
When creating a packed archive in a repository that has existing packs, the command reuses existing deltas. This sometimes results in a slightly suboptimal pack. This flag tells the command not to reuse existing deltas but compute them from scratch.
- --no-reuse-object
-
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.
- --compression=<n>
-
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.
- --[no-]sparse
-
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. - --thin
-
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.
Note : Un paquet mince viole le format d’archive empaquetĂ©e en omettant les objets requis et est donc inutilisable par Git sans le rendre autonome. Utilisez
git index-pack --fix-thin
(voir git-index-pack[1]) pour restaurer la propriété autonome. - --shallow
-
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.
- --delta-base-offset
-
A packed archive can express the base object of a delta as either a 20-byte object name or as an offset in the stream, but ancient versions of Git don’t understand the latter. By default, git pack-objects only uses the former format for better compatibility. This option allows the command to use the latter format for compactness. Depending on the average delta chain length, this option typically shrinks the resulting packfile by 3-5 per-cent.
Note : Les commandes de porcelaine comme
git gc
(voir git-gc[1]),git repack
(voir git-repack[1]) passent cette option par défaut dans le Git moderne quand ils mettent des objets dans votre dépôt dans des fichiers paquets. Ainsi faitgit bundle
(voir git-bundle[1]) quand il crée un colis. - --threads=<n>
-
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. - --index-version=<version>[,<dĂ©calage>]
-
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Ă©.
- --keep-true-parents
-
Avec cette option, les parents qui sont cachés par des greffes sont néanmoins empaquetées.
- --filter=<spéc. du filtre>
-
Omits certain objects (usually blobs) from the resulting packfile. See git-rev-list[1] for valid
<filter-spec>
forms. - --no-filter
-
DĂ©sactive tout argument
--filter=
précédent. - --missing=<action-manquante>
-
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.
La forme --missing=error demande que pack-objects s’arrĂŞte avec une erreur si un objet manquant est rencontrĂ©. Si le dĂ©pĂ´t est un clone partiel, une tentative de rĂ©cupĂ©ration des objets manquants sera effectuĂ©e avant de les dĂ©clarer manquants. C’est l’action par dĂ©faut.
La forme --missing=allow-any permet de continuer le parcours d’objet si un objet manquant est rencontrĂ©. Il n’y aura pas de rĂ©cupĂ©ration d’un objet manquant. Les objets manquants seront silencieusement omis des rĂ©sultats.
Le forme --missing=allow-promisor est comme allow-any, mais ne permettra la traversĂ©e d’objets de continuer que pour les objets manquants du promettant EXPECTED. Il n’y aura pas de rĂ©cupĂ©ration d’un objet manquant. Les objets manquants inattendus entraĂ®neront une erreur.
- --exclude-promisor-objects
-
Omit objects that are known to be in the promisor remote. (This option has the purpose of operating only on locally created objects, so that when we repack, we still maintain a distinction between locally created objects [without .promisor] and objects from the promisor remote [with .promisor].) This is used with partial clone.
- --keep-unreachable
-
Objects unreachable from the refs in packs named with --unpacked= option are added to the resulting pack, in addition to the reachable objects that are not in packs marked with *.keep files. This implies
--revs
. - --pack-loose-unreachable
-
Empaqueter les objets seuls inaccessibles (et leurs homologues seuls enlevés). Cela implique
--revs
. - --unpack-unreachable
-
Garder les objets inaccessibles sous forme libre. Cela implique
--revs
. - --delta-islands
-
Restreindre les correspondances de delta basées sur des "îlots". Voir ÎLOTS DE DELTA ci-dessous.
ĂŽLOTS DE DELTA
Dans la mesure du possible, pack-object
tente de rĂ©utiliser les deltas existants sur disque pour Ă©viter d’avoir Ă rechercher de nouveaux Ă la volĂ©e. C’est une optimisation importante dans le serveur lors des rĂ©cupĂ©rations, parce que cela signifie que le serveur peut Ă©viter de dĂ©compresser la plupart des objets et simplement envoyer les octets directement Ă partir du disque. Cette optimisation ne peut pas fonctionner quand un objet est stockĂ© comme un delta contre une base que le rĂ©cepteur n’a pas (et que nous n’envoyons pas dĂ©jĂ ). Dans ce cas, le serveur « brise » le delta et doit en trouver un nouveau, ce qui a un coĂ»t CPU Ă©levĂ©. Par consĂ©quent, il est important pour la performance que l’ensemble des objets dans les relations de delta sur disque correspondent Ă ce qu’un client allait rĂ©cupĂ©rer.
Dans un dĂ©pĂ´t normal, cela tend Ă fonctionner automatiquement. Les objets sont gĂ©nĂ©ralement accessibles depuis les branches et les Ă©tiquettes, et c’est ce que les clients rĂ©cupèrent. Tous les deltas que nous trouvons sur le serveur sont susceptibles d’ĂŞtre entre des objets que le client a ou aura.
Mais dans certaines configurations de dĂ©pĂ´t, vous pouvez avoir plusieurs groupes de sommets de rĂ©fs connexes mais sĂ©parĂ©s, avec des clients qui ont tendance Ă rĂ©cupĂ©rer ces groupes indĂ©pendamment. Par exemple, imaginez que vous hĂ©bergez plusieurs « bifurcations » d’un dĂ©pĂ´t dans un seul dĂ©pĂ´t d’objets partagĂ©s, et que les clients les considèrent comme des dĂ©pĂ´ts sĂ©parĂ©s via GIT_NAMESPACE
ou des dĂ©pĂ´ts sĂ©parĂ©s Ă l’aide d’un autre mĂ©canisme. Un rĂ©-empaquetage naĂŻf peut trouver que le delta optimal pour un objet est contre une base qui se trouve seulement dans une autre bifurcations. Mais quand un client rĂ©cupère, il n’aura pas l’objet de base, et il faudra trouver un nouveau delta Ă la volĂ©e.
A similar situation may exist if you have many refs outside of refs/heads/
and refs/tags/
that point to related objects (e.g., refs/pull
or refs/changes
used by some hosting providers). By default, clients fetch only heads and tags, and deltas against objects found only in those other groups cannot be sent as-is.
Delta islands solve this problem by allowing you to group your refs into distinct "islands". Pack-objects computes which objects are reachable from which islands, and refuses to make a delta from an object A
against a base which is not present in all of A
's islands. This results in slightly larger packs (because we miss some delta opportunities), but guarantees that a fetch of one island will not have to recompute deltas on the fly due to crossing island boundaries.
When repacking with delta islands the delta window tends to get clogged with candidates that are forbidden by the config. Repacking with a big --window helps (and doesn’t take as long as it otherwise might because we can reject some object pairs based on islands before doing any computation on the content).
Islands are configured via the pack.island
option, which can be specified multiple times. Each value is a left-anchored regular expressions matching refnames. For example:
[pack] island = refs/heads/ island = refs/tags/
puts heads and tags into an island (whose name is the empty string; see below for more on naming). Any refs which do not match those regular expressions (e.g., refs/pull/123
) is not in any island. Any object which is reachable only from refs/pull/
(but not heads or tags) is therefore not a candidate to be used as a base for refs/heads/
.
Refs are grouped into islands based on their "names", and two regexes that produce the same name are considered to be in the same island. The names are computed from the regexes by concatenating any capture groups from the regex, with a - dash in between. (And if there are no capture groups, then the name is the empty string, as in the above example.) This allows you to create arbitrary numbers of islands. Only up to 14 such capture groups are supported though.
Par exemple, imaginez que vous stockez les réfs pour chaque bifurcation dans refs/virtual/ID
, oĂą ID
est un identifiant numérique. Vous pouvez alors configurer :
[pack] island = refs/virtual/([0-9]+)/heads/ island = refs/virtual/([0-9]+)/tags/ island = refs/virtual/([0-9]+)/(pull)/
Cela met les têtes et les étiquettes pour chaque bifurcation dans leur propre îlot (nommée "1234" ou similaire), et les réfs à tirer pour chaque invocation dans leur propre "1234-pull".
Notez que nous choisissons un îlot unique pour y loger chaque regex, en utilisant le classement "le dernier gagne"(qui permet à la configuration par-dépôt de prendre la priorité sur la configuration au niveau utilisateur, et ainsi de suite).
CONFIGURATION
Diverses variables de configuration affectent l’empaquetage, voir git-config[1] (recherchez "paquet" et "delta").
En particulier, la compression de delta n’est pas utilisĂ©e sur des objets plus grands que la variable de configuration core.bigFileThreshold
et sur des fichiers avec l’attribut `delta ` rĂ©glĂ© Ă false.
GIT
Fait partie de la suite git[1]
TRADUCTION
Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .