Par Anonyme (non vérifié) , 29 avril 2026

Budgets de repack

Quand Git calcule des deltas durant le repack, il considère une fenêtre d'objets base candidats par cible. Des fenêtres plus grandes produisent des packs plus petits mais utilisent plus de mémoire et CPU.

Boutons clés

[pack]
windowMemory = 256m
threads = 0
deltaCacheSize = 256m
deltaCacheLimit = 1000
window = 10
depth = 50
sizeLimit = 2g
bigFileThreshold = 512m

Repack avec budgets personnalisés

git repack -adf --window=250 --depth=50 \
  --window-memory=512m --threads=8 \
  --write-midx --write-bitmap-index

Mathématiques de mémoire

La mémoire totale est approximativement pack.threads × pack.windowMemory + pack.deltaCacheSize.

git -c pack.threads=2 -c pack.windowMemory=128m repack -adf

Réglage serveur

[uploadpack]
packObjectsHook = /usr/local/bin/pack-objects-wrapper
[pack]
threads = 4
windowMemory = 128m

Seuil gros fichier

git config core.bigFileThreshold 50m

Erreurs courantes

Définir --window=2000 en espérant des packs plus serrés sans tester la mémoire — OOM suit.

Mesurer l'effet

du -sh .git/objects/pack/
git verify-pack -v .git/objects/pack/pack-*.idx | tail -3
GIT_TRACE2_PERF=1 git repack -adf 2>&1 | tail -20