¿Cómo puedo dañar un repository de Git?

¿Cuáles son algunas maneras de crear un repository de git corrupto? ¿Hay forms de dañar permanentemente un repository git de forma interesante? ¿Se puede paralizar un repository git de modo que se comporta de forma un tanto normal, pero hace cosas extrañas?

Mi interés proviene de cuando alguien está preocupado acerca de si realmente han creado un estado irrecuperable. Por lo general, resulta ser algo fácil de solucionar o al less para rebuild. ¿Hay gems escondidas ( malvadas ) en git?

Bueno, la corrupción más directa que puede ocurrir es la pérdida de datos o integridad de datos dentro del directory .git/objects . Como está diseñado para ser un mecanismo de almacenamiento de escritura inmutable, una vez que viola esa suposition, muchas otras cosas se desmoronarán. Lo más común es que esto sea causado por packages que se dañaron en la transmisión de networking, por ejemplo. A less que seas muy (léase: astronómicamente) desafortunado, sin embargo, git detectará esto como una cuestión de rutina y se quejará en voz alta. Para get una falla silenciosa de esta manera, necesitarás corromper un blob de tal manera que preserve su hash SHA1 … bajo compression de desinflado … con un encabezado preciso de tipo y tamaño.

Entonces, git es bastante bueno para verificar su propia integridad de datos. qué más podemos hacer? Para realmente hacer que el estado sea irrecuperable , necesita:

  1. Las confirmaciones y otros objects asociados con ese estado no serán referencedos (es decir, no accesibles por ninguna reference nombrada bajo .git/refs refs o cualquier reflog); entonces
  2. Recolección de basura para eliminar el estado para siempre, o para tomar un clon nuevo y eliminar el original.

De lo contrario, siempre podrás ejecutar git checkout <sha> && git branch recovenetworking y recuperar todo tu trabajo, sin importar lo que hayas hecho. Los commits son huérfanos como este durante el uso normal de git cuando rebase, cherry-pick o filter-branch, todos los cuales crean nuevos objects de compromiso basados ​​en los antiguos, o si se git reset --hard una twig alnetworkingedor. De forma pnetworkingeterminada, tiene un período de gracia de aproximadamente dos semanas antes de que se eliminen, entonces, aunque siempre puede truncar su reflog y podar manualmente para activar algo temprano.

Mucho más a menudo, he visto la pérdida de datos cuando los usuarios nunca agregan sus datos a GIT en primer lugar. Los usuarios nuevos a veces dudan en comprometerse con frecuencia e intentan usar commands con una copy de trabajo sucia, por ejemplo. Si nunca registra un estado en git, ¡git no puede devolvérselo!

Si estás de acuerdo con las trapacerías recuperables pero difíciles de notar , puedes hacer algo de maldad con los puntos de reemploop o injerto de git para engañar a git para que opere en un historial falso con fusiones o operaciones de filtrar twigs. Sin embargo, las confirmaciones reemplazadas siguen contando como alcanzables, por lo que no será un daño permanente.