Au lieu empaqueter progressivement les objets non empaquetés, empaqueter tout ce qui est référencé dans un seul paquet. Particulièrement utile lors de l’empaquetage d’un dépôt utilisé pour un développement privé. À utilliser avec -d. Cela nettoie les objets que git prune a laissé, mais que git fsck --full --dangling montre comme en suspens.

Même que -a, sauf si -d est utilisé. Ensuite, tous les objets inaccessibles dans un paquet précédent deviennent des objets libres, non empaquetés, au lieu d’être laissés dans l’ancien paquet. Les objets inaccessibles ne sont jamais intentionnellement ajoutés à un paquet, même en rempaquetant. Cette option empêche les objets inaccessibles d’être immédiatement supprimés parce qu’ils sont laissés dans l’ancien paquet et ensuite enlevés. Au lieu de cela, les objets non joignables libres seront élagués selon les règles d’expiration normales avec la prochaine invocation de git gc. Voir git-gc[1].

Après l’empaquetage, si les paquets nouvellement créés rendent quelques paquets existants redondants, retirer les paquets redondants. Lancer également git prune-packed pour supprimer les fichiers d’objets libres redondants.

Identique à -a, sauf si -d est utilisé. Ensuite, tous les objets inaccessibles sont empaquetés dans un paquet déchet séparé. Les objets inaccessibles peuvent être élagués selon les règles d’expiration normales avec l’invocation suivante de git gc (voir git-gc[1]). Incompatible avec -k.

Expirer les objets inaccessibles plus âgés que <date-approx> immédiatement au lieu d’attendre la prochaine invocation git gc. Seulement utile avec --cruft -d.

Rempaqueter les objets en paquets d’au plus <n> octets avant de créer de nouveaux paquets. Tant qu’il y a assez de paquets déchets plus petits que <n>, le rempaquetage créera un nouveau paquet déchet contenant les objets de tous les paquets déchets combinés, en plus de tous les nouveaux objets inaccessibles. Les paquets déchets plus grands que <n> ne seront pas modifiés. Lorsqu’un nouveau paquet déchet est plus grand que les <n>_octets, il est divisé en plusieurs paquets, qui sont tous garantis d’avoir une taille d’au plus _<n> octets. Seulement utile avec --cruft -d.

Écrire un paquet déchet contenant des objets élagués (le cas échéant) dans le répertoire <rép>. Cette option est utile pour conserver une copie de tous les objets élagués dans un répertoire séparé comme sauvegarde. Seulement utile avec --cruft -d.

Passer l’option --local à git pack-objects. Voir git-pack-objects[1].

Passer l’option --no-reuse-delta à git-pack-objects. Voir git-pack-objects[1].

Passer l’option --no-reuse-object à git-pack-objects. Voir git-pack-objects[1].

N’afficher aucune progression sur le flux d’erreur standard et passer l’option -q à git pack-objects. Voir git-pack-objects[1].

Ne pas mettre à jour les informations du serveur avec git update-server-info. Cette option ignore la mise à jour des fichiers de catalogue locaux nécessaires pour publier ce dépôt (ou une copie directe de celui-ci) sur HTTP ou FTP. Voir git-update-server-info[1].

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 est passée à git pack-objects.

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. Notez que l’utilisation réelle de la mémoire sera la limite multipliée par le nombre de threads utilisés par git-pack-objects[1].

La taille maximum de chaque fichier paquet. La taille peut être suffixée avec "k", "m", ou "g". La taille minimale autorisée est limitée à 1 MiB. Si spécifiée, plusieurs fichiers paquets seront créés, ce qui empêche la création d’un index de bitmap. 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.

Retirer les objets correspondant à la spécification du filtre du fichier paquet résultant et les mettre dans un fichier paquet séparé. Notez que les objets utilisés dans le répertoire de travail ne sont pas filtrés. Donc, pour que la séparation fonctionne pleinement, il est préférable de l’exécuter dans un dépôt nu et d’utiliser les options -a et -d avec cette option. --no-write-bitmap-index (ou l’option de config repack.writebitmaps à false) devrait aussi être utilisés, sinon l’écriture de l’index de bitmap échouera, vu que cela supposerait l’écriture d’un seul fichier paquet contenant tous les objets. Voir git-rev-list[1] pour les forme valides de <spéc-de-filtre>.

Écrire le paquet contenant des objets filtrés vers le répertoire <répertoire>. Seulement utile avec --filter. Ceci peut être utilisé pour mettre le paquet dans un répertoire d’objets séparé qui est accessible par le mécanisme alternatif de Git. ATTENTION : Si le fichier paquet contenant les objets filtrés n’est pas accessible, le dépôt peut se corrompre car il pourrait ne pas être possible d’accéder aux objets dans ce fichier. Voir les sections objects et objects/info/alternates de gitrepository-layout[5].

Écrire un index de bitmap accessible dans le cadre du rempaquetage. Cela n’a de sens que lorsqu’utilisé avec -a, -A ou -m, car les bitmaps doivent pouvoir se référer à tous les objets accessibles. Cette option annule le réglage de repack.writeBitmaps. Cette option n’a aucun effet si plusieurs paquets sont créés, à moins d’écrire un MIDX (auquel cas un bitmap multi-pack est créé).

Inclure des objets dans les fichiers .keep lors du rempaquetage. Notez que nous ne supprimons toujours pas les paquets .keep après la fin de pack-objects . Cela signifie que nous pouvons dupliquer des objets, mais cela rend l’option sûre lorsqu’il y a des poussées ou des récupérations simultanées. Cette option n’est généralement utile que si vous écrivez des bitmaps avec -b ou repack.writeBitmaps, car elle garantit que le paquet géré par le bitmap a les objets nécessaires.

Exclure le paquet donné du réempaquetage. C’est équivalent à avoir un fichier .keep sur le paquet.<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.

Lors de la libération des objets inaccessibles, ne pas s’ennuyer à relâcher des objets plus anciens que <quand>. Cela peut être utilisé pour optimiser l’écriture de tous les objets qui seraient immédiatement élagués par un `git prune`subséquent.

Lorsqu’utilisé avec -ad, tous les objets inaccessibles des paquets existants seront annexés à la fin du paquet au lieu d’être enlevés. De plus, tous les objets inaccessibles seront empaquetés (et leurs homologues libres enlevés).

Passer l’option --delta-islands à git-pack-objects, voir git-pack-objects[1].

Arranger la structure de paquets résultant de sorte que chaque paquet successif contient au moins <facteur> fois le nombre d’objets que le plus grand paquet existant .

Écrire un index multi-paquet (voir git-multi-pack-index[1]) contenant les paquets non redondants.