Resumo

  • O plano oficial de 2018 escolheu SHA-256 e propôs uma tabela bidirecional entre nomes antigos e novos de objetos. Era uma arquitetura de transição, não a descrição de uma ponte pronta.
  • O manual do Git 2.29.0 tratou o formato SHA-256 como experimental em 2020. O manual do Git 2.54.0 ainda dizia, em 2026, que repositórios SHA-1 e SHA-256 não tinham interoperabilidade.

O arquivo inclui o endereço do vizinho

Imagine um conjunto de caixas identificadas pela impressão digital de seu conteúdo. Para uma caixa que guarda apenas um arquivo, calcular uma impressão nova pode ser direto. Mas as caixas que organizam as demais anotam os endereços de seus vizinhos. É assim com as árvores e os commits do Git. O documento de transição explica que mudar o nome de um objeto altera os bytes de quem o referencia. Quem teve os bytes alterados ganha outro nome. A operação segue as ligações da história; o problema não mora apenas na largura de um identificador.

Os nomes SHA-1 já apareciam em repositórios existentes, servidores e ferramentas externas. Para permitir conversa entre esses sistemas e novos repositórios SHA-256, seria preciso relacionar os nomes dos mesmos objetos nas duas formas. O algoritmo de hash entrega uma impressão do conteúdo; a correspondência histórica precisa ser mantida por software. Uma tabela de tradução, nesse caso, vale mais do que um cartaz anunciando a nova fórmula.

O desenho de 2018 previa exatamente uma relação nos dois sentidos. Sua ambição era converter um repositório de cada vez e preservar comunicação com servidores SHA-1. Também delimitava etapas e deixava suporte a um novo protocolo fora da primeira implementação. O projeto via o destino, mas não confundia a linha no mapa com uma estrada em funcionamento.

Criar foi possível antes de compartilhar

Em 2020, o Git 2.29.0 já aceitava --object-format=sha256 na criação do repositório. O manual avisava que era experimental, destinado a testes e geralmente incapaz de compartilhar trabalho com um repositório SHA-1. Essa observação põe cada entrega no seu lugar: criar um histórico local e trocá-lo com a rede antiga são capacidades diferentes.

O manual do Git 2.54.0 manteve sha1 como padrão em 2026 e ofereceu sha256 como opção. Também afirmou que ainda não existia interoperabilidade entre repositórios dos dois formatos. A promessa arquitetônica de 2018 não pode ser cobrada como se estivesse instalada por causa de um parâmetro no comando de inicialização.

O plano BreakingChanges mira SHA-256 como padrão para novos repositórios no Git 3.0. Não define data e depende de bibliotecas, aplicativos e serviços de hospedagem prontos. O projeto tampouco planeja, por ora, aposentar o formato SHA-1. O futuro pode começar com uma porta nova enquanto o passado continua trabalhando pela porta antiga. É uma coexistência deliberada, com custos de compatibilidade bem concretos.

A história cobrou participação de todos

O plano citava a fraqueza de SHA-1 e a colisão SHAttered de 2017 ao justificar SHA-256. A razão para trocar era clara. A dificuldade estava em nomes embutidos nos objetos e em software fora do controle de uma única equipe. O Git podia escolher a função; não podia obrigar cada servidor e ferramenta dependente a entender as duas genealogias no mesmo dia. A diferença entre o projeto de 2018 e o aviso de 2026 é a medida dessa dependência. Em sistemas endereçados pelo conteúdo, nomes são estrutura, não papelaria.