Quali operazioni Git bloccano il database?

Question

Git ha una varietà di operazioni per la lettura/scrittura nel proprio database interno. Ho letto che le operazioni di scrittura sono atomiche in Git. Tuttavia, per altre operazioni come le letture, quali operazioni bloccheranno il database?

In particolare, sto scrivendo un'applicazione che chiamerà contemporaneamente "git blame" e voglio assicurarmi che sia qualcosa che posso multithread.

Answer 1

Non ho controllato questo nella fonte, ma dalla conoscenza della struttura interna di git, direi che tutto a parte lo git gc può essere multithread.

Git è solo un gruppo di file oggetto che si richiamano l'un l'altro, ma sono autorizzati a fare riferimento in un'unica direzione ("il passato"). A parte i capi delle diramazioni, il contenuto di un repository git non può essere modificato (solo esteso) e l'git gc è l'unica operazione che eliminerà roba da un repository git.

Ecco perché git richiede un blocco minimo assoluto e anche perché si dovrebbe andare bene. Si noti che l'indice è escluso da tutto questo - che sarà frequentemente bloccato, ma git blame HEAD e ogni comando che verrebbe eseguito su un repository nudo non utilizzerà l'indice.

Answer 2

Il blocco minimo è effettivamente necessario.

L'unica avvertenza è quando si esegue varigit gc contemporaneamente, come illustrato da commit ed7eda8 da Kyle J. McKay (mackyle) per Git 1,9/2,0 (Q1 2014), effettivamente Git 1.8.5.3, pubblicato 15 gennaio 2014.

Dal 64a99eb4 (git 1.8.5), git gc rifiuta di funzionare senza l'opzione --force seun altro processo gc sullo stesso repository è già in esecuzione.

Tuttavia, se il repository è condivisa e utente A corre git gc sul repository e mentre quell'utente gc è ancora in esecuzione B corre git gc sullo stesso repository il processo gc gestito dall'utente A non sarà notato e il gc gestito dall'utente B andrà avanti ed eseguirà.

Il problema è che il test kill(pid, 0) riesce con un errore EPERM dato utente B non è consentito per segnalare i processi eseguiti dall'utente A (meno che l'utente è Broot).

Aggiornare il test per riconoscere un errore EPERM nel senso che il processo esiste e un altro gc non deve essere eseguito (a meno che non sia indicato --force).

Quindi, a meno che non ci si trovi in ​​tale scenario, è possibile chiamare altri comandi git contemporaneamente senza alcun problema.