Quali sono i limiti del file in Git (numero e dimensione)?

Qualcuno sa quali sono i limiti Git per il numero di file e la dimensione dei file?

Questo messaggio di Linus può aiutarti con altri limiti

[…] CVS, cioè finisce per essere praticamente orientato verso un modello “un file alla volta”.

Il che è bello in quanto puoi avere un milione di file, e poi provarne solo alcuni – non vedrai mai l’impatto degli altri 999.995 file.

Git fondamentalmente non guarda mai meno dell’intero repository. Anche se si limita un po ‘le cose (es. Controlla solo una porzione, o se la storia torna indietro di poco), git finisce sempre con la cura di tutto e portando avanti la conoscenza.

Quindi git scala davvero male se lo costringi a guardare tutto come un enorme repository. Non penso che quella parte sia davvero risolvibile, anche se probabilmente possiamo migliorarla.

E sì, poi ci sono i problemi del “grande file”. Non so davvero cosa fare con i file enormi. Li succhiamo, lo so.

Vedi di più nella mia altra risposta : il limite con Git è che ogni repository deve rappresentare un ” insieme coerente di file “, il “tutto il sistema” in sé (non è ansible taggare “parte di un repository”).
Se il tuo sistema è composto da parti autonome (ma interdipendenti), devi utilizzare i sottomoduli .

Come illustrato dalla risposta di Talljoe , il limite può essere un sistema (un gran numero di file), ma se capisci la natura di Git (sulla coerenza dei dati rappresentata dai suoi tasti SHA-1), realizzerai il vero “limite” è uno di uso : cioè, non dovresti provare a memorizzare tutto in un repository Git, a meno che non sei pronto a ricevere o taggare sempre tutto. Per alcuni progetti di grandi dimensioni, non avrebbe senso.


Per uno sguardo più approfondito ai limiti git, vedi ” git con file di grandi dimensioni ”
(che cita git-lfs : una soluzione per archiviare file di grandi dimensioni al di fuori del repository git.GitHub, aprile 2015)

I tre problemi che limitano un repository git:

  • file enormi ( xdelta per packfile è solo in memoria, cosa che non va bene con file di grandi dimensioni)
  • un numero enorme di file , ovvero un file per blob e un lento git gc per generare un file pack alla volta.
  • enormi packfile , con un indice di file pack inefficiente per recuperare i dati dal (enorme) packfile.

Una discussione più recente (febbraio 2015) illustra i fattori limitanti per un repository Git :

Anche alcuni cloni simultanei dal server centrale rallenteranno altre operazioni concorrenti per altri utenti?

Non ci sono blocchi nel server durante la clonazione, quindi in teoria la clonazione non influenza altre operazioni. La clonazione può tuttavia utilizzare molta memoria (e molta cpu a meno che non attivi la funzionalità bitmap di raggiungibilità, cosa che dovresti).

git pull ‘ sarà lento?

Se escludiamo il lato server, la dimensione del tuo albero è il fattore principale , ma i tuoi file 25k dovrebbero andare bene (linux ha 48k file).

git push ‘?

Questo non è influenzato da quanto è profonda la cronologia del tuo repository, o quanto è largo il tuo albero, quindi dovrebbe essere veloce ..

Ah il numero di ref può influenzare sia git-push che git-pull .
Penso che Stefan conosca meglio di me in quest’area.

git commit ‘? (È elencato come lento nel riferimento 3 ). ‘ git status ‘? (Rallenta di nuovo nel riferimento 3 anche se non lo vedo).
(anche git-add )

Di nuovo, la dimensione del tuo albero. A misura del tuo repository, non penso che ti debba preoccupare.

Alcune operazioni potrebbero non sembrare quotidiane, ma se vengono chiamate frequentemente dal front-end Web a GitLab / Stash / GitHub ecc, possono diventare colli di bottiglia. (ad esempio ‘ git branch --contains ‘ sembra terribilmente influenzato negativamente da un gran numero di filiali).

git-blame potrebbe essere lento quando un file viene modificato molto.

Non esiste un limite reale: tutto è denominato con un nome a 160 bit. La dimensione del file deve essere rappresentabile in un numero a 64 bit, quindi non ci sono limiti reali.

C’è un limite pratico, però. Ho un repository di ~ 8 GB con> 880.000 e git gc richiede un po ‘di tempo. L’albero di lavoro è piuttosto grande, quindi le operazioni che controllano l’intera directory di lavoro richiedono un po ‘di tempo. Questo repository viene utilizzato solo per l’archiviazione dei dati, quindi, è solo un mucchio di strumenti automatizzati che lo gestiscono. Tirare le modifiche dal repository è molto, molto più veloce rispetto alla rsyncing degli stessi dati.

 %find . -type f | wc -l 791887 %time git add . git add . 6.48s user 13.53s system 55% cpu 36.121 total %time git status # On branch master nothing to commit (working directory clean) git status 0.00s user 0.01s system 0% cpu 47.169 total %du -sh . 29G . %cd .git %du -sh . 7.9G . 

Se aggiungete file troppo grandi (GB nel mio caso, Cygwin, XP, 3 GB di RAM), aspettatevi questo.

fatale: memoria insufficiente, malloc fallita

Maggiori dettagli qui

Aggiornamento 3/2/11: visto simile in Windows 7 x64 con Tortoise Git. Tonnellate di memoria utilizzate, risposta del sistema molto lenta.

Nel febbraio 2012, c’era una discussione molto interessante sulla mailing list di Git di Joshua Redstone, un ingegnere informatico di Facebook che testava Git su un enorme repository di test:

Il repository di test ha 4 milioni di commit, la storia lineare e circa 1,3 milioni di file.

I test eseguiti dimostrano che per tale repo Git è inutilizzabile (operazione a freddo che dura alcuni minuti), ma questo potrebbe cambiare in futuro. Fondamentalmente, la performance è penalizzata dal numero di chiamate stat() al modulo FS del kernel, quindi dipenderà dal numero di file nel repository e dall’efficienza della cache di FS. Vedi anche questo Gist per ulteriori discussioni.

Dipende da cosa è il tuo significato. Ci sono limiti di dimensioni pratiche (se hai un sacco di file di grandi dimensioni, può diventare noiosamente lento). Se si dispone di molti file, anche le scansioni possono rallentare.

Tuttavia, non ci sono limiti intrinseci al modello. Puoi certamente usarlo male e essere infelice.

Penso che sia bene cercare di evitare che i file di grandi dimensioni commettano come parte del repository (ad esempio un dump del database potrebbe essere meglio altrove), ma se si considera la dimensione del kernel nel proprio repository, è probabile che si possa pensare a lavorare comodamente con qualcosa di più piccolo e meno complesso di quello.

Ho una grande quantità di dati che sono memorizzati nel mio repository come singoli frammenti JSON. Ci sono circa 75.000 file che si trovano sotto poche directory e non è davvero dannoso per le prestazioni.

Il loro controllo alla prima volta era, ovviamente, un po ‘lento.

Ho trovato questo tentativo di memorizzare un numero enorme di file (350k +) in un repository. Sì, negozio. Ride.

 $ time git add . git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total 

I seguenti estratti dalla documentazione di Bitbucket sono piuttosto interessanti.

Quando lavori con un repository DVCS clonando, spingi, stai lavorando con l’intero repository e tutta la sua storia. In pratica, una volta che il tuo repository diventa più grande di 500 MB, potresti iniziare a vedere i problemi.

… Il 94% dei clienti di Bitbucket ha repository inferiori a 500 MB. Sia il Kernel Linux che Android sono sotto 900MB.

La soluzione consigliata su quella pagina è dividere il tuo progetto in blocchi più piccoli.

A partire dal 2018-04-20 Git per Windows ha un bug che effettivamente limita le dimensioni del file a 4 GB max utilizzando quella particolare implementazione (questo bug si propaga anche a lfs ).

git ha un limite di 4G (32 bit) per il repo.

http://code.google.com/p/support/wiki/GitFAQ