¿Por qué git usa hashes en lugar de números de revisión?

Siempre me pregunté por qué git prefiere los hashes sobre los números de revisión. Los números de revisión son mucho más claros y fáciles de consultar (en mi opinión): ¡Hay una diferencia entre decirle a alguien que eche un vistazo a la revisión 1200 o cometa 92ba93e! (Solo para dar un ejemplo).

Entonces, ¿hay alguna razón para este diseño?

Un solo número de revisión, que aumenta monotónicamente, solo tiene sentido para un sistema de control de versiones centralizado, donde todas las revisiones fluyen a un solo lugar que puede rastrear y asignar números. Una vez que ingresa al mundo DVCS, donde existen numerosas copias del repositorio y los cambios se extraen y se envían a ellos en flujos de trabajo arbitrarios, el concepto simplemente no se aplica. (Por ejemplo, no hay un solo lugar para asignar números de revisión; si bifurco su repositorio y decide un año después retirar mis cambios, ¿cómo podría un sistema garantizar que nuestros números de revisión no entren en conflicto?)

Necesita hashes en un sistema distribuido. Digamos que usted y un colega están trabajando en el mismo repositorio y que ambos realizan un cambio localmente y luego lo presionan. ¿Quién será el número de revisión 1200 y quién es el número de revisión 1201 dado que ninguna de las partes tiene conocimiento el uno del otro? La única solución técnica realista es crear un hash de los cambios utilizando un método conocido y vincular las cosas en función de eso.

Curiosamente, HG admite números de versión, pero son explícitamente una característica solo local: su repositorio tiene un conjunto, el repositorio de su compañero de trabajo tendrá un conjunto diferente dependiendo de cómo lo empujaron y lo que tiraron. Sin embargo, hace que el uso de la línea de comandos sea un poco más amigable que Git.

Integridad de los datos.

Respetuosamente estoy en desacuerdo con las respuestas actuales. Los hashes no son necesarios para un DVCS, vea el camino del Bazar . Podría hacerlo también con cualquier otro tipo de identificador único global. Los hash son una medida para garantizar la integridad de los datos: representan un resumen de la información contenida en el objeto (commit, árboles, ...) al que hace referencia el hash. Se cree que alterar el contenido sin alterar el hash (es decir, un ataque de preimagen o un ataque de colisión ) es difícil, aunque no imposible. (Si realmente te gusta, mira el artículo de 2011 de Marc Stevens ).

Por lo tanto, hacer referencia a los objetos por su hash SHA permite verificar si el contenido ha sido manipulado. Y, dado que están (casi) garantizados como únicos, también se pueden usar como identificadores de revisión, convenientemente.

Vea el Capítulo 9 del libro de Git para más detalles.

En palabras simples:

• Los hashes están destinados a ser casi universalmente únicos. NO está garantizado, pero es extremadamente improbable que se generen los mismos SHA para contenido diferente. En términos prácticos para un proyecto dado, puede tratarlo como único.
• Con los números de revisión, tendría que usar un espacio de nombres para referirse específicamente a la revisión 1200.
• Git puede funcionar tanto distribuido como centralizado. Entonces, ¿cómo se obtienen los números de revisión correctos y únicos?
• También el uso de números de revisión crearía la falsa expectativa de que las revisiones más recientes deberían tener números más altos, y eso no sería cierto debido a la ramificación, fusión, rebase, etc.
• Siempre tienes la opción de poner etiquetas a los commits.

En términos matemáticos:

• Se requeriría un orden total sobre las confirmaciones de Git para números de versión monotonalmente crecientes.
• Los commits de Git forman un gráfico acíclico dirigido (DAG) que solo se puede ordenar parcial / topológicamente .

Hash no es la solución única para VCS distribuido. Pero cuando se trata con un sistema distribuido, solo se puede registrar el orden parcial de los eventos. (Para VCS, el evento puede ser una confirmación). Es por eso que es imposible mantener un número de revisión que aumente monotónicamente. Por lo general, adoptamos algo como el reloj vectorial (o la marca de tiempo del vector) para registrar dicha relación de orden parcial. Esta es la solución utilizada en Bazar .

Pero, ¿por qué Git no usa el reloj vectorial sino el hash? Creo que la causa raíz es la selección de cerezas . Cuando realizamos una selección de cereza en un repositorio, el orden parcial de las confirmaciones está cambiando. Los relojes vectoriales de algunos commits deben reasignarse para representar el nuevo orden parcial. Sin embargo, tal reasignación en el sistema distribuido induciría relojes vectoriales inconsistentes. Ese es el verdadero problema con el que lidian los hashes.