¿Qué tan robustos son los compromisos de Git cuando se va la luz?

Un día estaba usando Git (todavía lo estoy usando) y la electricidad se cortó mientras me comprometía.

Cuando volví (en realidad, la electricidad), el repositorio git estaba corrupto. No recuerdo el nombre exacto, pero era algo así como "referencias inválidas" o algo así.

Es fácil adivinar que la confirmación se rompió en el medio de la operación (me estaba comprometiendo a través de IntelliJ, que realiza las adiciones de índice automáticamente). También fue fácil adivinar que, en realidad, 'commit' no es tan ACID como la operación DBMS con el mismo nombre.

P : ¿Hay alguna manera de garantizar que las operaciones de repo-alteración respeten la atomicidad? es decir, si la electricidad vuelve a caer, y me estoy comprometiendo, me gustaría que mi sistema de archivos no esté en un estado corrupto.

No sé si hay una manera de hacer que Git commits sobreviva fallas de energía perfectamente programadas, pero es posible que pueda reparar su repositorio.

Se supone que los objetos Git son inmutables, por lo que todas sus confirmaciones anteriores aún deberían ser válidas. De acuerdo con esta respuesta , puede cambiar el hash .git/refs/heads/<branch-name>para cambiar el encabezado de la rama en la que estaba trabajando a la confirmación anterior (puede verlos en .git/logs/HEAD).

El comentario a esa respuesta dice que este método "todavía deja el repositorio en estado roto, pero esto permite recuperarlo". No he probado esto (no tengo idea de cómo replicar su situación), pero supongo que la recuperación se realiza a través de git gc, eso eliminará la confirmación corrupta.

El sistema de almacenamiento de Git no es transaccional, por lo que definitivamente existe la posibilidad de que un problema de hardware pueda dejar las cosas en un estado inconsistente. Por otro lado, Git también es muy rápido, por lo que tendría que ser muy desafortunado para ser golpeado por problemas del tipo de "falla de energía" (los problemas sistemáticos con el disco son otra cosa). La velocidad proviene en parte precisamente del hecho de que no es transaccional; Las transacciones son realmente bastante caras ya que tienen que esperar la confirmación del disco de que ha escrito los datos. (Las bases de datos hacen todo tipo de cosas para tratar de ocultar este costo, pero finalmente pagan el precio. Algunos de los DVCS de la competencia son transaccionales, y sí, son bastante más lentos en el mismo hardware que git).

En el peor de los casos, una falla catastrófica total del disco (que he visto suceder), la única forma de que cualquier DVCS se recupere es usar el hecho de que está distribuido. Si ha empujado sus cambios hasta hace muy poco tiempo a otro sistema y los ha compartido con muchos hosts diferentes, la recuperación es solo una cuestión de utilizar uno de estos otros lugares como fuente de artefactos, un lugar desde donde extraer sus ramas ( incluso si solo temporalmente). De este modo, volverá a incluir la historia de las ramas interesantes y podrá volver a trabajar muy rápidamente; cualquier cosa que borre muchas copias distribuidas de su repositorio a la vez es un desastre del tipo en el que no se preocupa por la programación posterior (piense en el impacto de un meteorito importante) o es una acción directa del enemigo. (Trate de no hacer tales enemigos ...) Esto está en contraste total con los sistemas no distribuidos, donde perder el servidor central que aloja todo es un golpe fatal.