Por que o git usa hashes em vez de números de revisão?

Eu sempre me perguntei por que o git prefere hashes sobre números de revisão. Os números de revisão são muito mais claros e fáceis de consultar (na minha opinião): Há uma diferença entre dizer a alguém para dar uma olhada na revisão 1200 ou confirmar 92ba93e! (Apenas para dar um exemplo).

Então, existe alguma razão para esse design?

Um único número de revisão monotonicamente crescente só faz sentido para um sistema de controle de versão centralizado, onde todas as revisões fluem para um único local que pode rastrear e atribuir números. Quando você entra no mundo do DVCS, onde existem inúmeras cópias do repositório e as alterações são extraídas e enviadas a eles em fluxos de trabalho arbitrários, o conceito simplesmente não se aplica. (Por exemplo, não há um lugar para atribuir números de revisão - se eu bifurcar seu repositório e você decidir, um ano depois, fazer minhas alterações, como um sistema poderia garantir que nossos números de revisão não entrem em conflito?)

Você precisa de hashes em um sistema distribuído. Digamos que você e um colega estejam trabalhando no mesmo repositório e que ambos realizem uma alteração localmente e depois enviem. Quem passa a ser a revisão número 1200 e quem é a revisão número 1201, dado que nenhuma das partes tem conhecimento um do outro? A única solução técnica realista é criar um hash das alterações usando um método conhecido e vincular as coisas com base nisso.

Curiosamente, o HG suporta números de versão, mas eles são explicitamente um recurso apenas local - seu repositório tem um conjunto, o repositório do seu colega de trabalho terá um conjunto diferente, dependendo de como eles foram empurrados e puxados. Isso torna o uso da linha de comando um pouco mais amigável do que o Git.

Integridade de dados.

Discordo respeitosamente das respostas atuais. Hashes não são necessários para um DVCS, veja o caminho do Bazar . Você poderia fazer o mesmo com qualquer outro tipo de identificador globalmente exclusivo. Os hashes são uma medida para garantir a integridade dos dados: eles representam um resumo das informações contidas no objeto (confirmação, árvores, ...) referido pelo hash. Acredita-se que alterar o conteúdo sem alterar o hash (isto é, um ataque de pré - imagem ou ataque de colisão ) seja difícil, embora não impossível. (Se você realmente gosta, dê uma olhada no artigo de 2011 de Marc Stevens ).

Portanto, a referência aos objetos por seu hash SHA permite verificar se o conteúdo foi violado. E, desde que eles sejam (quase) garantidos exclusivos, eles também podem ser usados ​​como identificadores de revisão - convenientemente.

Veja o Capítulo 9 do livro Git para mais detalhes.

Nas palavras dos leigos:

• Os hashes devem ser quase universalmente únicos. NÃO é garantido, mas é extremamente improvável que os mesmos SHAs sejam gerados para conteúdo diferente. Em termos práticos, para um determinado projeto, você pode tratá-lo como único.
• Com os números de revisão, você precisaria usar um espaço para nome para se referir especificamente à revisão 1200.
• O Git pode trabalhar distribuído e / ou centralizado. Então, como você obtém os números de revisão corretos e exclusivos?
• O uso de números de revisão também criaria uma falsa percepção de que as revisões mais recentes deveriam ter números mais altos, o que não seria verdade por causa de ramificações, mesclagens, rebatizações etc.
• Você sempre tem a opção de colocar tags em confirmações.

Em termos matemáticos:

• Um pedido total sobre as confirmações do Git seria necessário para aumentar o número de versões monotonicamente.
• As confirmações do Git formam um gráfico acíclico direcionado (DAG) que só pode ser pedido parcialmente / topologicamente .

Hash não é a solução exclusiva para VCS distribuído. Porém, quando lidamos com um sistema distribuído, apenas a ordem parcial dos eventos pode ser registrada. (Para o VCS, o evento pode ser um commit.) É por isso que é impossível manter um número de revisão monotonicamente crescente. Geralmente adotamos algo como relógio vetorial (ou carimbo de data e hora do vetor) para registrar essa relação de ordem parcial. Esta é a solução usada no Bazaar .

Mas por que o Git não usa relógio de vetor, mas hash? Eu acho que a causa raiz é a escolha da cereja . Quando executamos a seleção de cereja em um repositório, a ordem parcial de confirmações está mudando. Alguns relógios vetoriais de consolidação devem ser redesignados para representar a nova ordem parcial. No entanto, essa reatribuição no sistema distribuído induziria relógios vetoriais inconsistentes. Esse é o problema real com o qual os hashes lidam.