Quanto è robusto Git si impegna quando si spegne la corrente?

Un giorno stavo usando Git (lo sto ancora usando) e l'elettricità è andata giù mentre stavo impegnando.

Quando sono tornato (in realtà l'elettricità), il repository git era corrotto. Non ricordo il nome esatto, ma era qualcosa come "riferimenti non validi" o qualcosa del genere.

È facile indovinare che il commit è stato interrotto nel mezzo dell'operazione (stavo eseguendo il commit tramite IntelliJ, che esegue automaticamente le aggiunte dell'indice). Era anche facile indovinare che, in realtà, "commit" non è ACID come l'operazione DBMS con lo stesso nome.

D : Esiste un modo per garantire che le operazioni di modifica dei pronti contro termine rispettino l'atomicità? cioè se l'elettricità scende di nuovo, e lo sto impegnando, vorrei che il mio filesystem non fosse in uno stato corrotto.

Non so se c'è un modo per far sì che Git si impegni a sopravvivere a interruzioni di corrente perfettamente temporizzate, ma potresti essere in grado di correggere il tuo repository.

Gli oggetti Git dovrebbero essere immutabili, quindi tutti i tuoi commit precedenti dovrebbero essere ancora validi. In base a questa risposta , puoi modificare l'hash in .git/refs/heads/<branch-name>per cambiare la testa del ramo su cui stavi lavorando al commit precedente (puoi vederli in .git/logs/HEAD).

Il commento a quella risposta afferma che questo metodo "Lascia ancora il repository nello stato non funzionante, ma ciò consente di recuperarlo". Non l'ho testato (non ho idea di come replicare la tua situazione), ma suppongo che il ripristino venga eseguito tramite git gc, che eliminerà il commit danneggiato.

Il sistema di archiviazione di Git non è transazionale, quindi c'è sicuramente la possibilità che un problema hardware possa lasciare le cose in uno stato incoerente. D'altra parte, Git è anche molto veloce, quindi dovresti essere davvero sfortunato per essere colpito da problemi del tipo "mancanza di corrente" (i problemi sistematici con il disco sono qualcos'altro). La velocità deriva in parte proprio dal fatto che non è transazionale; le transazioni sono davvero piuttosto costose poiché devono attendere la conferma dal disco che ha scritto i dati. (I database fanno tutto il possibile per cercare di nascondere questo costo, ma alla fine pagano comunque il prezzo. Alcuni DVCS concorrenti sono transazionali e, sì, sono un po 'più lenti sullo stesso hardware di git.)

Nel peggiore dei casi - un guasto del disco catastrofico totale (che ho visto accadere) - l'unico modo per recuperare qualsiasi DVCS è usare il fatto che è distribuito. Se hai inviato le tue modifiche fino a poco tempo fa a un altro sistema e le hanno condivise con molti host diversi, il recupero è solo una questione di utilizzo di uno di questi altri luoghi come fonte di artefatti, un luogo da cui estrarre i tuoi rami ( anche se solo temporaneamente). In questo modo riporterai indietro la storia dei rami interessanti e potrai riprendere a lavorare molto rapidamente; tutto ciò che cancella un sacco di copie distribuite del tuo repository in una volta è o un disastro del tipo in cui non ti preoccupi della programmazione in seguito (pensa al grande impatto del meteorite) o è una vera azione nemica. (Cerca di non creare nemici del genere ...) Questo è in totale contrasto con i sistemi non distribuiti, dove perdere il server centrale che ospita tutto è un duro colpo.