Quanto è strong l'impegno di Git quando si spegne l'alimentazione?

Question

Quanto è strong l'impegno di Git quando si spegne l'alimentazione?

#1 da (10 voti)
#2 da (10 voti)

24

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

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

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

Q : esiste un modo per garantire che le operazioni di repo-modifica rispettino l'atomicità? Ad esempio, se l'elettricità si interrompe di nuovo e sto eseguendo il commit, mi piacerebbe che il mio filesystem non si trovasse in uno stato corrotto.

git

posta Luis Masuelli 16.05.2014 - 00:12

fonte

2 risposte

Leggi altre domande sui tag git

Come gestisci il design in Scrum? Che cosa tenere a mente quando si rilascia un'applicazione che utilizza librerie con licenza con la licenza Apache 2.0?

score 10 · Answer 1

Non so se c'è un modo per far sopravvivere i commit di Git a scadenze perfette, ma potresti essere in grado di riparare il tuo repository.

Gli oggetti Git dovrebbero essere immutabili, quindi tutti i tuoi vecchi commit dovrebbero essere ancora validi. Secondo questa risposta , puoi cambiare l'hash in .git/refs/heads/<branch-name> per cambiare il capo del ramo su cui stavi lavorando il commit precedente (puoi vederli in .git/logs/HEAD ).

Il commento a quella risposta dice che questo metodo "lascia il repository ancora in uno stato rotto, ma questo permette di recuperarlo". Non ho provato questo (non ho idea di come replicare la situazione), ma presumo che il ripristino avvenga tramite git gc , che cancellerà il commit corrotto.

score 10 · Answer 2

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 di tipo "power failure" (problemi sistematici con il disco sono qualcos'altro). La velocità arriva in parte proprio dal fatto che non è transazionale; le transazioni sono davvero piuttosto costose dal momento che devono attendere la conferma dal disco che ha scritto i dati. (I database fanno ogni genere di cose per cercare di nascondere questo costo, ma alla fine pagano ancora il prezzo. Alcuni dei concorrenti DVCSes sono transazionali, e sì, sono un po 'più lenti sullo stesso hardware come git.)

Nel peggiore dei casi - un totale disastro del disco catastrofico (che ho visto accadere) - l'unico modo per qualsiasi DVCS di recuperare è usare il fatto che è distribuito . Se hai spostato le tue modifiche fino a poco tempo fa in un altro sistema e le hai condivise con molti host diversi, il recupero è solo una questione di utilizzare uno di questi altri luoghi come fonte di artefatto, un luogo in cui estrarre i tuoi rami ( anche se solo temporaneamente). In questo modo tornerai indietro nella storia dei rami interessanti e sarai in grado di tornare a lavorare molto velocemente; tutto ciò che cancella tutte le copie distribuite del tuo repository in una sola volta è un disastro del genere in cui non ti preoccupi di programmare in seguito (pensa all'impatto di un meteorite) o è un'azione nemica. (Cerca di non fare tali nemici ...) Questo è in totale contrasto con i sistemi non distribuiti, dove perdere il server centrale che ospita tutto è un colpo fatale.