Che cosa significa "Imballaggio automatico del repository per prestazioni ottimali"?


225

Sto riscontrando un problema con il mio repository git. Negli ultimi due giorni ogni volta che faccio una push sul server ricevo questo messaggio: "Imballaggio automatico del repository per prestazioni ottimali", e non sembra andare via e restituire la shell.

Ho anche provato a fare il checkout su un nuovo ramo e poi fare un rebase sul mio ramo precedente e poi ho fatto git gcper rimuovere gli oggetti della cronologia inutilizzati e poi ho fatto un push ma appare ancora questo messaggio. Per favore fatemi sapere cosa sta succedendo con il mio repository.

Risposte:


305

Versione breve: significa quello che dice, e se lo lasci finire, tutto andrà bene.

Durante la maggior parte delle operazioni che possono potenzialmente aumentare il numero di oggetti sfusi (non compressi) nel repository (inclusi i push), Git invoca git gc --auto. Se ci sono abbastanza oggetti sciolti (per impostazione predefinita, almeno 6700), verrà quindi richiamato git repack -d -lper impacchettarli. Se ci sono troppi pacchetti separati, li imballerà anche in uno.

Un pacchetto è un singolo file compresso con delta, contenente un numero elevato di oggetti. È più efficiente archiviare oggetti in pacchetti, ma ci vuole tempo per comprimere (comprimere) oggetti, quindi Git inizialmente crea oggetti sciolti, quindi li impacchetta in lotti di tanto in tanto, tramite l'invocazione automatica di git gc --auto.

Se lasci che Git finisca di reimballare, questo non accadrà più per un po '. In effetti, può richiedere del tempo, soprattutto se si hanno molti oggetti binari di grandi dimensioni, ma se si sta attivando, significa che probabilmente ridurrà drasticamente la quantità di spazio su disco occupato dal repository. Se davvero non vuoi che accada, puoi modificare il parametro config gc.auto. Se lo aumenti a qualcosa di molto più grande di 6700, accadrà meno frequentemente, ma impiegherà più tempo. Se lo diminuisci, dovrà comunque eseguire il repack corrente, ma successivamente succederà più spesso e finirà più rapidamente. Se lo si imposta su 0, disabiliterà il reimballaggio automatico.

Vedi man git-gc(sotto --auto) e man git-config(sotto gc.auto) per maggiori informazioni.


14
In effetti, ci sono voluti circa 5 minuti per me, ma è finito. Bella risposta.
Joshua Pinter

6
Lo stiamo vedendo accadere ad ogni pressione (facendo qualche istante, eh).

2
@dpk: ciò non dovrebbe accadere in circostanze normali - il numero di oggetti in una singola spinta non dovrebbe essere abbastanza grande da attivarlo (a meno che il tuo repository non sia enorme e / o stai spingendo un sacco di commit), quindi una volta che ha avuto successo completa (lo stai lasciando completo, giusto?) non dovrebbe succedere di nuovo fino a quando non ti accumuli. Se non riesci a capirlo, fai una domanda separata.
Cascabel,

6
"Se lasci che Git finisca", e può ... fatal: Out of memory, malloc failed (tried to allocate 79610689 bytes) error: failed to run repack- questo è quello che ottengo per mettere tutto il nostro codebase in un repository git. Suppongo che ucciderò le app e
forzerò il

11
Lo capisco ogni volta che faccio un tiro di sbieco. Ho fatto un manuale git gc, ma succede ancora ogni volta che tiro. Strano.
Barry Kelly,

51

Mentre Jefroni ha ragione sul fatto che a volte l'imballaggio automatico richiede solo tempo per essere completato, se il messaggio di impacchettamento automatico persiste per più giorni come descritto da OP, ci sono buone probabilità che la pulizia di git manchi oggetti penzolanti, come descritto in questa domanda .

Per vedere se gli oggetti sospesi attivano i messaggi in corso sull'imballaggio automatico, prova a eseguire git fsck. Se ottieni un lungo elenco di commit penzolanti, puoi pulirli con

git gc --prune=now

Di solito devo eseguirlo sul mio repository ogni 2-3 mesi quando il messaggio di impacchettamento automatico non scompare dopo un singolo pull.


5
Pur non essendo la risposta accettata, questo era esattamente ciò di cui avevo bisogno. Ho ricevuto il messaggio ogni volta che ho fatto git pull, per diversi giorni, e in fsckeffetti ha mostrato un sacco di impegni penzolanti.
Jörn Zaefferer,

36

Per disabilitare per un progetto:

cd your_project_dir
git config gc.auto 0

Per disabilitare a livello globale:

git config --global gc.auto 0

2
Penso di aver scoperto come: andare nella cartella .git, aprire il file di configurazione, eliminare il testo 'auto = 0' e salvare. Ciò sembra riattivare l'autopacking.
Adrian Keister,

18
git config --unset gc.auto
jtatum

10

Git esegue git-repack, che racchiude molti oggetti (= file, commit e alberi) in un file pack. Git lo fa a volte, quando un euristico dice che può esserci spazio risparmiato (un file pack contiene delta di oggetti compressi, mentre ogni file nella directory objects / contiene il contenuto compresso del file completo)


2

Speriamo che quel git gc --autopassaggio sia ora (git 2.0.1, 25 giugno 2014) più efficiente.
Vedi commit 62aad18 di Nguyễn Thái Ngọc Duy ( pclouds)

gc --auto: non blocca i riferimenti in background

9f673f9 ( gc: opzione di configurazione per l'esecuzione di --auto in background - 2014-02-08, Git 2.0.0) mette " gc --auto" in background per ridurre i tempi di attesa dell'utente.
Parte della raccolta dei rifiuti è ref-pack e reflog di potatura. Questi richiedono il blocco di alcuni ref e possono interrompere altri processi nel tentativo di bloccare lo stesso ref.

Se gc --autoviene attivato nel mezzo di uno script, i blocchi di blocco di gc in background potrebbero non riuscire nello script, cosa che non potrebbe mai accadere prima di 9f673f9 .

Continua a funzionare pack-refse " reflog --prune" in primo piano per interrompere gli aggiornamenti ref paralleli. Le restanti operazioni in background (repack, potatura e rerere) non dovrebbero influire sull'esecuzione dei processi git.

E Git 2.22 (Q2 2019) ottimizza ulteriormentegit gc .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.