¿Cómo maneja Git (Hub) posibles colisiones de SHA cortos?

Question

Tanto Git como GitHub muestran versiones cortas de SHA, solo los primeros 7 caracteres en lugar de los 40, y tanto Git como GitHub admiten tomar estos SHA cortos como argumentos.

E.g. git show 962a9e8

E.g. https://github.com/joyent/node/commit/962a9e8

Dado que el espacio de posibilidad ahora es de órdenes de magnitud inferior, "solo" 268 million, ¿cómo protegen Git y GitHub contra colisiones aquí? ¿Y cómo los manejan?

Answer 1

Estas formas cortas son solo para simplificar el reconocimiento visual y para hacer su vida easier. Git realmente no trunca nada, internamente todo se manejará con el valor completo. Sin embargo, puede usar un SHA-1 parcial a su conveniencia:

Git es lo suficientemente inteligente como para descubrir qué cometido debe escribir si proporciona los primeros caracteres, siempre que su SHA-1 parcial sea al menos cuatro caracteres largos y no ambiguos, es decir, solo un objeto en el repositorio actual comienza con ese SHA-1 parcial.

Answer 2

Tengo un repositorio que tiene una confirmación con un ID de 000182eacf99cde27d5916aa415921924b82972c.

git show 00018 

muestra la revisión, pero

git show 0001 

impresiones

error: short SHA1 0001 is ambiguous. 
error: short SHA1 0001 is ambiguous. 
fatal: ambiguous argument '0001': unknown revision or path not in the working tree. 
Use '--' to separate paths from revisions 

(Si tienes curiosidad, que es un clon del repositorio git para git sí; que cometen es uno que Linus Torvalds hizo en 2005.)

Answer 3

Dos notas aquí:

• Si escribe y cualquier lugar de la página de GitHub mostrar una confirmación, podrás ver los 40 bytes completos de dicho cometió.
  Eso ilustra el punto de emboss: GitHub no trunca nada.

• Y 7 bits no es suficiente desde 2010 de todos modos.
  Ver commit dce9648 por el propio Linus Torwalds (oct 2010, Git 1.7.4.4):

El valor por defecto de 7 viene de bastante temprano en el desarrollo git, cuando siete dígitos hexadecimales era mucho (Cubre alrededor Más de 250 millones de valores hash). En aquel entonces, pensaba que las revisiones de 65k eran muchas (era lo que estábamos a punto de alcanzar en BK), y cada revisión suele ser de unos 5-10 objetos nuevos, así que un millón de objetos era un número grande.

(BK = Bitkeeper)

En estos días, el núcleo no es ni siquiera el proyecto Git más grande, e incluso el núcleo tiene unos 220k revisiones ( mucho más grande que el árbol BK nunca fue) y nos acercamos a dos millones de objetos. En ese punto, siete dígitos hexadecimales siguen siendo únicos para muchos de ellos, pero cuando estamos hablando de solo dos órdenes de diferencia de magnitud entre el número de objetos y el tamaño hash, habrá colisiones en valores hash truncados. Ya no está ni cerca de ser poco realista, sucede todo el tiempo.

Ambos deberíamos aumentar la abreviatura predeterminada que era poco realista, y agregar una forma para que las personas establezcan su propio proyecto por defecto en el archivo de configuración de git.