Git 2.56 chega com git history drop e Git 3.0 deve trocar SHA-1 por SHA-256

O Git 2.56 reúne mais de 700 commits não-merge e chega sem alterar a experiência central do controle de versão, mas com peças que apontam para a transição maior do Git 3.0. O destaque funcional é o subcomando git history drop, ainda experimental, que remove um commit da branch atual e reaplica os commits seguintes. O release também mostra sinais de um projeto que está segurando parte do trabalho mais significativo para o futuro. Em setembro, o maintainer Junio Hamano perguntou à comunidade se o próximo release deveria ser o 3.0 ou se ainda haveria versões 2.x antes disso. A cobertura da LWN mostra que a resposta envolve decisões estruturantes: trocar SHA-1 por SHA-256 como hash padrão, adotar o formato reftable para referências e conviver com quebras de compatibilidade controladas.

git history drop remove commits, mas esbarra em merges

O comando git history drop commit-id faz o que o nome sugere: remove o commit indicado da linha atual e replica os commits que vieram depois dele. É uma alternativa mais direta a fluxos de git rebase interativo para eliminar um commit problemático, sem reescrever manualmente a lista de commits. O comando faz parte da caixa de ferramentas ainda experimental do git history.

A limitação central é que ele se recusa a funcionar quando a história contém commits de merge. Como boa parte dos repositórios reais mantém merges, o recurso fica indisponível justamente nos cenários em que a remoção cirúrgica de um commit costuma ser mais delicada. Por isso, o git history drop deve ser tratado como ferramenta de nicho para histórias lineares até que o Git estenda o suporte.

git refs ganha verbos diretos

O Git 2.56 adiciona subcomandos a um comando que já existia para manipulação de referências em baixo nível. Agora git refs create, git refs delete, git refs update e git refs rename executam exatamente as operações que seus nomes indicam — algo que o material apurado destaca como surpreendentemente direto para o Git.

Na prática, isso reduz a dependência de scripts que combinam comandos de baixo nível ou de invocações a plumbing commands. Para quem mantém ferramentas internas que criam, movem ou removem branches e tags, a existência de verbos oficiais tende a deixar o código mais legível e menos sujeito a variações entre versões. Também facilita auditorias e testes, porque o comportamento passa a ter um nome único e documentado no próprio comando.

Ajustes de usabilidade que evitam atrito

A versão também traz pequenas mudanças que somam no dia a dia. git branch --delete-merged remove branches locais que já foram incorporadas às respectivas remote tracking branches, reduzindo a limpeza manual. Já git branch -d passa a falhar com mensagem útil quando a branch está sendo usada em uma bisseção, evitando interrupções acidentais de um processo de caça a regressões.

Outro ajuste é a repetição de tentativas ao travar o arquivo de configuração, o que diminui a chance de falha quando múltiplos comandos tentam modificar a configuração simultaneamente. git add --resolved entra como opção para adicionar apenas arquivos que tiveram conflitos de merge já resolvidos. E git status agora sugere git pull quando a branch está atrás da branch rastreada — mas a mensagem continua dizendo "up to date" se a defasagem estiver em uma remote tracking branch que ainda não foi atualizada por um git fetch. Essa distinção importa: o status compara com a referência local, não com o estado real do remoto até que um git fetch aconteça.

Git 3.0 coloca o SHA-256 no centro

A decisão mais relevante para o futuro próximo é a troca do SHA-1 pelo SHA-256 como hash padrão. Hashes identificam todos os objetos do repositório — arquivos, árvores de diretórios e commits — e servem para verificar a cadeia de commits. O SHA-1 é considerado fraco há tempos; se puder ser quebrado, isso permitiria modificar a história de um repositório de forma difícil ou impossível de detectar.

O Git já inclui defesas contra os ataques conhecidos ao SHA-1, e poucos desenvolvedores parecem seriamente preocupados com comprometimento agora. Ainda assim, migrar para uma função hash mais segura faz sentido, especialmente porque o custo de manter compatibilidade com SHA-1 tende a crescer. O suporte não experimental ao SHA-256 existe desde o Git 2.42, lançado em 2023, embora parte da interoperabilidade com repositórios antigos tenha demorado mais. GitLab tem suporte desde 2024, e Forgejo também. O GitHub ainda é a ausência mais notável: lançar uma versão do Git que cria repositórios incompatíveis com o GitHub seria um problema sério. Brian m. carlson, funcionário do GitHub e desenvolvedor central da transição SHA-256, respondeu à discussão dizendo que novidades sobre esse suporte estavam a caminho e que fazer o próximo release como 3.0 talvez fosse a melhor escolha, conforme a nota da LWN.

Carlson também propôs uma mudança de comportamento aparentemente pequena: o Git deixaria de aceitar IDs em maiúsculas. Hoje, f00f00 e F00F00 são tratados como o mesmo ID, e essa ambiguidade já gerou bugs e vulnerabilidades. Aceitar apenas minúsculas deve afetar poucos usuários, mas é uma quebra de compatibilidade que reforça o caráter do 3.0 como versão de ruptura controlada.

Reftable muda o armazenamento de referências

Referências em Git são associações entre um nome e um objeto; branches, tags e remotes são refs. O mecanismo padrão atual guarda cada ref como um arquivo em .git/refs/. Uma branch chamada foo, por exemplo, vira o arquivo .git/refs/heads/foo contendo o ID do commit da ponta. O packed-refs aglutina esses arquivos e melhora o desempenho até certo ponto, mas mantém a lógica baseada em percorrer referências para várias operações.

O problema aparece quando o número de refs cresce. A documentação do reftable citada no material aponta que o repositório Android tem mais de 800.000 refs. Nessa escala, buscar refs ou descobrir quais refs apontam para um commit específico fica caro, e essa lentidão aparece em operações comuns de inspeção ou integração. O Git 2.45 introduziu o reftable como alternativa: um arquivo binário otimizado para eficiência de espaço e acesso rápido. Desde então é possível criar repositórios com reftable, mas o formato nunca virou padrão.

A troca para reftable tende a ser invisível para quem usa apenas o Git, fora o ganho de desempenho. O risco está em outras ferramentas que acessam repositórios diretamente. Carlson mencionou o libgit2 como preocupação potencial, mas Patrick Steinhardt indicou que adicionou suporte a reftable à biblioteca e que o suporte a SHA-256 já estava habilitado por padrão desde agosto. Com isso, o libgit2 deixa de ser um bloqueador para o Git 3.0, ainda que outras ferramentas possam precisar de ajustes semelhantes.

O que ainda falta resolver

As ressalvas da transição são concretas. Repositórios que dependem do GitHub para hospedagem precisam aguardar o suporte oficial a SHA-256 antes de migrar sem atrito. Ferramentas que leem .git diretamente podem não estar preparadas para reftable, mesmo com o avanço do libgit2. A mudança para aceitar apenas IDs em minúsculas, embora pequena, pode quebrar scripts que normalizam hashes com maiúsculas ou que dependem da equivalência atual.

O próprio Git 2.56 carrega limitações visíveis: ``