Git 2.56 chega com git history drop — e o Git 3.0 já tem data marcada

O Git é daquelas ferramentas que a gente usa dezenas de vezes por dia e quase nunca lê o changelog. Vale abrir uma exceção agora: a versão 2.56, que fecha o ciclo no fim de setembro com mais de 700 commits (sem contar merges), traz comandos que mexem no dia a dia — e, logo atrás dela, o projeto já colocou no calendário a maior quebra de compatibilidade da sua história.

O que vem no 2.56

A novidade mais chamativa é o git history drop. Ele remove um commit específico do histórico do branch reaplicando os commits seguintes por cima — a operação que hoje exige um rebase interativo com edição manual da lista de tarefas. A limitação atual é relevante: ainda não funciona com merge commits.

# remove um commit do meio do histórico
git history drop 9f3c1ab

# manipulação direta de refs, sem plumbing
git refs create refs/heads/spike HEAD
git refs rename refs/heads/spike refs/heads/experimento

# limpeza de branches já integrados ao upstream
git branch --delete-merged

# adiciona só os arquivos com conflito resolvido
git add --resolved

Além disso, o release adiciona:

• git refs com os subcomandos create, delete, update e rename, dando uma interface de primeira classe para manipular referências.
• git branch --delete-merged, que apaga branches locais já integrados ao branch remoto correspondente.
• git add --resolved, que estagia apenas os arquivos cujo conflito foi resolvido e reclama se ainda sobraram marcadores de conflito no meio do código.
• git status passa a sugerir git pull quando o branch está atrás do que ele rastreia, e git branch -d se recusa a apagar um branch em uso por um bisect em andamento, explicando o motivo.
• O arquivo de configuração passa a tentar de novo ao falhar o lock, reduzindo erros quando dois processos escrevem config ao mesmo tempo.

Git 3.0: SHA-256, reftable e Rust obrigatório

O ponto de inflexão está marcado para abril de 2027. O Git 3.0 troca o SHA-1 pelo SHA-256 como algoritmo padrão de identificação de objetos. A fraqueza do SHA-1 é conhecida há anos e abre espaço, em tese, para manipulação de histórico difícil de detectar. Suporte não experimental a SHA-256 existe desde o Git 2.42, de 2023, mas a adoção real esbarra nas plataformas de hospedagem — o suporte do GitHub ainda não estava confirmado quando o assunto foi discutido, embora brian m. carlson, que conduz a transição, tenha sinalizado novidades a caminho.

A segunda mudança estrutural é o reftable, formato binário que substitui a árvore de arquivos em .git/refs. O ganho aparece em repositórios com muitas referências: o repositório do Android passa de 800 mil refs, e listar ou atualizar isso em arquivos soltos é caro. Patrick Steinhardt confirmou o suporte a reftable na libgit2, que já habilitou SHA-256 por padrão em agosto.

Duas mudanças menores completam o pacote e merecem atenção de quem escreve automação: object IDs em hexadecimal maiúsculo (F00F00) deixam de ser aceitos, apenas minúsculas valem — uma fonte antiga de ambiguidade e bugs; e o Git passa a exigir um compilador Rust funcionando para ser compilado, o que efetivamente tira do mapa plataformas sem toolchain Rust.

O calendário até lá

A transição é anunciada com antecedência incomum. Dezembro de 2026 traz a versão 2.98, sinalizando a virada. Em abril de 2027 saem simultaneamente a 2.99, como release de longo prazo para quem não pode migrar, e o Git 3.0, que vira a base de tudo que vier depois. Junio Hamano segue como mantenedor.

O que fazer agora

Não há urgência, mas há trabalho de casa. Criar um repositório novo com --object-format=sha256 e rodar a stack de CI, os hooks e as ferramentas internas contra ele é o jeito mais barato de descobrir o que quebra. Vale também checar se algum script seu compara object IDs sem normalizar caixa, e se as plataformas onde você compila Git a partir do fonte têm Rust disponível. Dezoito meses parece muito tempo — até o dia em que a migração for obrigatória.