Nota: você pode solicitar git rev-parse --shorto SHA1 mais curto e único.
Veja " git obter hash curto do hash regular "
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
Como você pode ver no meu exemplo, o SHA1 tem um comprimento de 5, mesmo que eu tenha especificado um comprimento de 4.
Para grandes repositórios, 7 não é suficiente desde 2010 e confirma o dce9648 pelo próprio Linus Torvalds (git 1.7.4.4, outubro de 2010):
O padrão 7 vem do início do desenvolvimento do git, quando havia sete dígitos hexadecimais (ele abrange mais de 250 milhões de valores de hash).
Naquela época, eu achava que 65k revisões eram muito (era o que estávamos prestes a atingir em BK), e cada revisão tende a ter entre 5 e 10 novos objetos, mais ou menos, portanto, um milhão de objetos era um grande número.
(BK = BitKeeper)
Hoje em dia, o kernel não é nem o maior projeto git, e até o kernel tem cerca de 220k de revisões ( muito maiores do que a árvore do BK) e estamos nos aproximando de dois milhões de objetos.
Nesse ponto, sete dígitos hexadecimais ainda são únicos para muitos deles, mas quando falamos de apenas duas ordens de diferença de magnitude entre o número de objetos e o tamanho do hash, haverá colisões nos valores de hash truncados.
Não é mais nem mesmo irrealista - acontece o tempo todo.
Devemos aumentar a abreviação padrão que é irrealisticamente pequena e adicionar uma maneira de as pessoas definirem seu próprio padrão por projeto no arquivo de configuração git .
core.abbrev
Defina o comprimento dos nomes dos objetos aos quais é abreviado.
Se não especificado, muitos comandos abreviam para 7 hexadígitos, o que pode não ser suficiente para nomes de objetos abreviados permanecerem exclusivos por um período de tempo suficiente.
environment.c:
int minimum_abbrev = 4, default_abbrev = 7;
Nota: Conforme comentado abaixo por marco.m , core.abbrevLengthfoi renomeado no core.abbrevmesmo Git 1.7.4.4 no commit a71f09f
Renomeie de core.abbrevlengthvolta paracore.abbrev
--abbrev=$nAfinal, corresponde à opção da linha de comando.
Mais recentemente, Linus adicionado em cometer e6c587c (para Git 2.11, Q4 2016):
(como mencionado no Matthieu Moy 's resposta )
Nos primeiros dias, decidimos, de alguma forma, abreviar nomes de objetos para 7 hexadígitos, mas à medida que os projetos crescem, é cada vez mais provável que nomes de objetos tão curtos sejam criados nos dias anteriores e registrados nas mensagens de log não sejam mais exclusivos.
Atualmente, o projeto do kernel do Linux precisa de 11 a 12 hexdigits, enquanto o próprio Git precisa de 10 hexdigits para identificar exclusivamente os objetos que eles têm, enquanto muitos projetos menores ainda podem ser compatíveis com o padrão original de 7 hexdigits. O tamanho único não serve para todos os projetos.
Introduzir um mecanismo, em que estimamos o número de objetos no repositório após a primeira solicitação para abreviar um nome de objeto com a configuração padrão e criar um padrão sadio para o repositório. Com base na expectativa de que 2^(2N)veríamos uma colisão em um repositório com objetos ao usar nomes de objetos reduzidos para os primeiros N bits, use número suficiente de hexdigits para cobrir o número de objetos no repositório.
Cada hexdigit (4 bits) que adicionamos ao nome abreviado nos permite ter quatro vezes (2 bits) quantos objetos no repositório.
Veja commit e6c587c (01/10/2016) por Linus Torvalds ( torvalds) .
Consulte commit 7b5b772 , commit 65acfea (01 out 2016) por Junio C Hamano ( gitster) .
(Mesclado por Junio C Hamano - gitster- in commit bb188d0 , 03 de outubro de 2016)
Essa nova propriedade (adivinhando um padrão razoável para o valor abreviado do SHA1) afeta diretamente como o Git calcula seu próprio número de versão para liberação .