O Novo Hash Padrão do Git – O Que Significa

O que este vídeo aborda

• Porque é que dois repositórios Git se podem recusar a comunicar?
• O que é que o Git 3 realmente muda?
• Porque substituir o SHA-1 se o Git deteta colisões?
• O que mostrou a nossa verificação de compatibilidade local?
• O que sobrevive a uma falha no Pi Durable?

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

Porque é que dois repositórios Git se podem recusar a comunicar?

0:00 Poderíamos pensar que atualizar o Git mantém as suas ferramentas a comunicar. O novo padrão de hash planeado do Git cria repositórios que o formato antigo atual não consegue comunicar. Neste vídeo, porque mudar? O que é que se quebra? Quem está pronto? Já existe uma exceção de trabalho no GitHub. Mostrarei o que ela prova no final. É sexta-feira, dois de outubro, e este é o The Daily Diff.

0:18 Na quinta-feira, um cofundador do GitHub chamou à mudança planeada do Git um erro dispendioso. O Pi lançou um novo agente de "harness", e o SvelteKit lançou outra migração. Scott Chacon ajudou a construir o GitHub e escreveu o Pro Git, por isso esta queixa vem de dentro de casa. A casa também vende ferramentas Git. Primeiro, o plano atual.

O que é que o Git 3 realmente muda?

0:35 O Git três usaria por padrão novos repositórios para SHA duzentos e cinquenta e seis, assim que as bibliotecas e os serviços de alojamento estivessem prontos para o suportar. O documento oficial não dá data de lançamento e mantém o SHA um suportado. O seu repositório existente não muda magicamente de formato quando atualiza o executável. Isso é importante lembrar antes que o seu chat em grupo agende uma migração de emergência. O drama é um padrão proposto, e o prazo é atualmente um calendário em branco.

Porque substituir o SHA-1 se o Git deteta colisões?

0:58 Porque mudar afinal? O Git nomeia objetos ao fazer o hash dos seus conteúdos. Os ficheiros alimentam árvores, e os "commits" referem-se a árvores e "commits" anteriores. Isso dá-lhe integridade em toda a história. Mude o esquema de hashing e os nomes dos objetos também mudam, incluindo as referências armazenadas dentro de outros objetos. Chacon remonta a Linus Torvalds, o criador do Git, argumentando que a distribuição

1:17 confiável é importante. Essa é uma posição histórica, e Linus escolheu o SHA um em dois mil e cinco. O caso de segurança mudou desde então. Pesquisadores demonstraram colisões SHA um em dois mil e dezassete, e mais tarde demonstraram um ataque de prefixo escolhido contra certificados de identidade PGP. O Git moderno deteta ataques de colisão conhecidos com SHA um "hardened". Os seus mantenedores também querem proteção contra ataques futuros, o que é razoável querer das assinaturas.

1:41 Chacon pensa que a conta do ecossistema compra pouca segurança. Ele propõe assinar um "checksum" forte separado do conteúdo da árvore, mantendo o endereçamento de objetos atual por baixo. O que se quebra? Criei ambos os formatos localmente e fiz o hash do mesmo pequeno ficheiro.

O que mostrou a nossa verificação de compatibilidade local?

1:54 Um nome de objeto tem quarenta caracteres hexadecimais, o outro tem sessenta e quatro. Depois tentei fazer um "fetch" entre eles. O meu Git instalado rejeitou-o com algoritmos incompatíveis, exatamente a lacuna de compatibilidade descrita no manual oficial atual. Isto usou o meu Git instalado antigo, por isso informa-nos sobre o limite atual. Chamá-lo um teste do Git três não lançado seria contabilidade criativa. O trabalho de migração atinge "scripts" que assumem o comprimento de um "hash", e sistemas que se ligam a nomes de objetos.

2:19 Re-fazer o hash de uma história precisa de um mapeamento entre essas identidades. O design de transição do Git inclui esse mapeamento e manuseamento de assinaturas. A prontidão da implementação é importante, porque um documento de design não atualiza a biblioteca escondida dentro da sua ferramenta de desenvolvimento favorita. Esse é o custo humano no argumento de Chacon. Cada mantenedor de ferramentas obtém outro trabalho de compatibilidade, enquanto os utilizadores descobrem que o seu controlo de versão agora precisa de controlo de versão. Por agora, teste o seu anfitrião e as suas ferramentas antes de escolher o novo formato para um

2:44 projeto. As equipas existentes podem manter o seu formato atual enquanto esse ecossistema se atualiza. Entretanto, o Pi chegou à versão um ponto zero.

O que sobrevive a uma falha no Pi Durable?

2:51 É um "harness" de agente de codificação da Earendil, com suporte nativo de MCP através do Codemode e ferramentas carregadas quando são necessárias. A equipa chama o minimalismo o ponto principal. Se a sua configuração de agente já se assemelha a um pequeno governo, manter as ferramentas fora do "prompt" até serem necessárias soa a reforma administrativa. Também lançou o Pi Durable, uma "framework" experimental separada. As tarefas guardam pontos de controlo para que um processo reiniciado possa retomar o trabalho inacabado do armazenamento persistente. O detalhe crucial é a repetição da ferramenta.

3:16 Uma ferramenta interrompida por uma falha só é executada novamente quando declara que é seguro. Caso contrário, o modelo é informado de que foi interrompido. Essa é uma fronteira útil quando uma ferramenta pode gastar dinheiro. Quero que o assistente se lembre da minha lista de compras sem celebrar uma falha comprando-a duas vezes.

O que é que o SvelteKit 3 migra por si?

3:30 O SvelteKit três também foi lançado na quinta-feira, movendo a configuração para o Vite e substituindo "dollar lib" por "hash lib", usando importações de subcaminhos de pacotes padrão. O comando de migração reescreve o que pode e deixa uma lista de tarefas para o resto. O seu robô pode ajudar, e o seu "diff" ainda merece ser lido. O anúncio até recruta os seus amigos robôs para as sobras. Estamos a chegar ao ponto em que uma atualização de "framework" entrega trabalhos de casa e um professor substituto sugerido. E as funções remotas ainda precisam do Async Svelte experimental.

3:56 Um número de versão principal parece reconfortante, mas as funcionalidades individuais têm as suas próprias etiquetas de maturidade. Verifique as que realmente está a usar.

O que prova a exceção de trabalho do GitHub?

4:03 Então, quem está pronto para o novo formato do Git? Aqui está essa exceção. Um repositório público do GitHub contendo a palestra de Brian Carlson já devolve um nome de objeto SHA duzentos e cinquenta e seis completo. Verifiquei o "remote" público diretamente. Os "slides" da palestra chamam o suporte de uma pré-visualização privada e dizem que a criação de repositórios ainda está a caminho. Há progresso real por trás da sala de espera. Isso prova que o GitHub pode servir este repositório de pré-visualização.

4:24 Isso não nos dá garantia nenhuma de que a criação de projetos comuns ou todas as suas integrações estejam prontas. A exceção tem um limite de permissão. Se preferir ler isto a ouvir-me dizer, o "diff" chega à sua caixa de entrada todas as manhãs, gratuitamente em "the daily diff dot dev", link abaixo. Portanto, o veredito de hoje é "needs review".

Porque é que o meu veredito depende de toda a cadeia de ferramentas?

4:40 Manteria a opção de "hash" mais forte e testaria toda a cadeia de ferramentas antes de alterar os padrões. A compatibilidade faz parte do envio da melhoria de segurança. E esse é o "diff" de hoje. Sou o Niko da Axrisi. Faça "merge" responsavelmente.

Fontes

1. Chaconblog.gitbutler.com
2. Git's official plangit-scm.com
3. Current interoperabilitygit-scm.com
4. Transition designgit-scm.com
5. Independent collision researchsha-mbles.github.io
6. GitHub preview repositorygithub.com
7. Pi 1.0earendil.com
8. Pi Durableearendil.com
9. SvelteKit 3svelte.dev
10. HN discussionnews.ycombinator.com