lo stato di git richiede troppo tempo

Question

Sto lavorando a un progetto in cui il sistema di controllo della versione è SVN e voglio usare git. Ho fatto un git svn clone ma il git status funziona terribilmente lento (circa 8 minuti). Il repository ha circa 63000 file e la maggior parte di essi sono librerie ignorate da git. È normale? Ho effettuato uno git prune && git gc per eseguire una pulizia degli oggetti non raggiungibili e un garbage collector. Ho anche fatto un git repack -Adf ma questo ha reso le cose ancora peggiori. Ci vuole anche più tempo (più di 20 minuti).

Cosa sto sbagliando? Questo è un progetto di Visual Studio e presumo che il file .gitignore non contenga le cose giuste. È possibile scoprire esattamente quali file sono generati da una build di Visual Studio e quali devono essere messi in versione?

Se il file .gitignore non è il problema, come posso rendere il mio git status più veloce, è normale per un progetto con 65000 file (circa 10 GB) funzionare così lentamente con git?

Answer 1

Per un repository di tale dimensione, git status e comandi associati possono essere molto lenti. Git funziona molto meglio quando i progetti sono presi in giro e separati, mentre Subversion tende a incoraggiare l'uso di singoli repository di behemoth contenenti più progetti, quindi questo tipo di problema non è raro quando si utilizza Git-SVN.

Tuttavia, ci sei alcune soluzioni che si possono usare per accelerare le cose:

• Se non lo avete già, l'aggiornamento a utilizzare un disco a stato solido piuttosto che un disco magnetico. Questo singolo cambiamento ha fatto una grande differenza per la velocità di Git quando stavo lavorando su un repository simile

• Guarda la sezione Configurazione di git help svn. Ciò descrive l'impostazione di Git-SVN per utilizzare le sottocartelle di traccia nel repository Subversion (ad esempio trunk/project-a, branches/*/project-a, tags/*/project-a, ...) piuttosto che l'intero repository. Se questo ha senso per il tuo repository, significa che puoi avere checkout molto più piccoli e run più veloci di git status.

• Vedere la sezione Sparse Checkout di git help read-tree. Questo ti spiegherà attraverso la configurazione di Git per usare una copia di lavoro sparsa, simile a un controllo di versioni secondarie di Subversion. Di nuovo, questo significa che ci saranno meno file di tracciamento di Git nella tua copia di lavoro, e quindi controllarli tutti saranno di nuovo più veloci.

• Considerare di impostare il flag "assume invariato" su ampie sezioni della copia di lavoro. Questo dirà a Git di non preoccuparsi di controllare se i file sono cambiati. Ci sono due modi per farlo:

  1. Per impostare il flag per cartelle specifiche, qualcosa di correre come il seguente:

     find <folder-name>... -type f -exec git update-index --assume-unchanged {} + 
     

  2. Per impostare il flag per l'intero repository (notare che questo perderà non impegnati modifiche):

     git config core.ignorestat true 
     git reset --hard HEAD 
     

  dare un'occhiata al l'opzione --assume-unchanged in git help update-index e la sezione config.ignoreStat in git help config per ulteriori informazioni su come funzionano.

  L'utilizzo di questi significherà è necessario specificare i percorsi ai comandi come git diff e git add esplicitamente, cioè comandi come una nuda git diff, git commit -a & c non funzionerà.

• Modificare il sistema operativo e/o il file system. Secondo le pagine man Git (le stesse del punto precedente), Windows 'lstat è lento, così come il file system CIFS. Sospetto che l'ideale sia qualcosa come ext3 o ext4 su Linux o qualche altro * nix.