# Novo Hash Predeterminado de Git – Que Significa

Published: 2026-10-02

O SHA-256 predeterminado proposto por Git crea un límite de compatibilidade para os novos repositorios. Revisamos o plan oficial, a obxección de Scott Chacon e unha excepción de vista previa de GitHub en funcionamento, despois cubrimos Pi 1.0 e SvelteKit 3. Veredito: NEEDS REVIEW.

Canonical: https://thedailydiff.dev/gl/video/2026-10-02-git-hash-split/

## Que abrangue este vídeo

- Por que dous repositorios de Git poden negarse a comunicarse?
- Que cambia realmente Git 3?
- Por que substituír SHA-1 se Git detecta colisións?
- Que mostrou a nosa comprobación de compatibilidade local?
- Que sobrevive a unha caída en Pi Durable?

## Capítulos

- 0:00 Por que dous repositorios de Git poden negarse a comunicarse?
- 0:34 Que cambia realmente Git 3?
- 0:58 Por que substituír SHA-1 se Git detecta colisións?
- 1:51 Que mostrou a nosa comprobación de compatibilidade local?
- 2:49 Que sobrevive a unha caída en Pi Durable?
- 3:30 Que migra SvelteKit 3 por ti?
- 4:03 Que proba a excepción de GitHub en funcionamento?
- 4:38 Por que o meu veredito depende de toda a cadea de ferramentas?

## Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

### Por que dous repositorios de Git poden negarse a comunicarse?

0:00 Pensarías que actualizar Git mantén as túas ferramentas comunicándose. O novo hash predeterminado planificado de Git crea repositorios que o formato antigo actual non pode comunicarse. Neste vídeo, por que cambiar? Que se rompe? Quen está listo? Xa hai unha excepción en funcionamento en GitHub. Mostrareiche o que proba ao final. É venres, dous de outubro, e isto é The Daily Diff.

0:18 O xoves, un cofundador de GitHub chamou ao cambio planificado de Git un erro custoso. Pi enviou un novo "agent harness", e SvelteKit enviou outra migración. Scott Chacon axudou a construír GitHub e escribiu Pro Git, polo que esta queixa vén de dentro da casa. A casa tamén vende ferramentas Git. Primeiro, o plan real.

### Que cambia realmente Git 3?

0:35 Git 3 establecería como predeterminado os novos repositorios a SHA 256, unha vez que as bibliotecas e os servizos de aloxamento estean listos para soportalo. O documento oficial non dá data de lanzamento e mantén SHA 1 soportado. O teu repositorio existente non cambia de formato máxicamente cando actualizas o executable. Iso é algo que vale a pena recordar antes de que o teu grupo programe unha migración de emerxencia. O drama é un valor predeterminado proposto, e o prazo é actualmente un calendario en branco.

### Por que substituír SHA-1 se Git detecta colisións?

0:58 Por que cambiar en absoluto? Git nomea obxectos mediante o "hashing" dos seus contidos. Os ficheiros aliméntanse en árbores, e os "commits" refírense a árbores e a "commits" anteriores. Iso dálle integridade a través do historial. Cambia o esquema de "hashing" e os nomes dos obxectos tamén cambian, incluíndo as referencias almacenadas dentro doutros obxectos. Chacon remóntase a Linus Torvalds, o creador de Git, argumentando que a distribución

1:17 de confianza importa. Esa é unha posición histórica, e Linus escolleu SHA 1 alá en 2005. O caso da seguridade moveuse desde entón. Os investigadores demostraron colisións SHA 1 en 2017, e máis tarde demostraron un ataque de prefixo escollido contra os certificados de identidade PGP. Git moderno detecta ataques de colisión coñecidos con SHA 1 endurecido. Os seus mantedores tamén queren protección contra futuros ataques, o cal é algo razoable de querer das sinaturas.

1:41 Chacon pensa que a factura do ecosistema compra pouca seguridade. Propón asinar un "checksum" forte separado do contido da árbore, mentres se mantén o enderezo de obxectos actual debaixo. Que se rompe? Creei ambos os formatos localmente e "hashee" o mesmo pequeno ficheiro.

### Que mostrou a nosa comprobación de compatibilidade local?

1:54 Un nome de obxecto ten 40 caracteres hexadecimais, o outro ten 64. Despois intentei "fetching" entre eles. O meu Git instalado rexeitouno con algoritmos non coincidentes, exactamente a brecha de compatibilidade descrita no manual oficial actual. Isto usou o meu Git antigo instalado, polo que nos di sobre o límite actual. Chamalo unha proba do Git 3 non lanzado sería contabilidade creativa. O traballo de migración alcanza os "scripts" que asumen a lonxitude dun "hash", e os sistemas que se vinculan a nomes de obxectos.

2:19 Volver a "hashear" un historial necesita un mapeo entre esas identidades. O deseño de transición de Git inclúe ese mapeo e o manexo de sinaturas. A preparación da implementación importa, porque un documento de deseño non actualiza a biblioteca que se esconde dentro da túa ferramenta de desenvolvemento favorita. Ese é o custo humano no argumento de Chacon. Cada mantedor de ferramentas ten outro traballo de compatibilidade, mentres os usuarios descobren que o seu control de versións agora necesita control de versións. Por agora, proba o teu "host" e as túas ferramentas antes de escoller o novo formato para un

2:44 proxecto. Os equipos existentes poden manter o seu formato actual mentres ese ecosistema ponse ao día. Mentres tanto, Pi alcanzou a versión 1.0.

### Que sobrevive a unha caída en Pi Durable?

2:51 É un "agent harness" de codificación de Earendil, con soporte nativo de MCP a través de Codemode e ferramentas cargadas cando son necesarias. O equipo chama minimalismo o punto. Se a túa configuración de axente xa se asemella a un pequeno goberno, manter as ferramentas fóra da petición ata que sexan necesarias soa a reforma administrativa. Tamén lanzou Pi Durable, un marco experimental separado. As tarefas gardan puntos de control para que un proceso reiniciado poida retomar o traballo inacabado do almacenamento persistente. O detalle crucial é a reprodución de ferramentas.

3:16 Unha ferramenta interrompida por un fallo só se executa de novo cando declara que é segura. Se non, ao modelo indícaselle que foi interrompido. Ese é un límite útil cando unha ferramenta pode gastar diñeiro. Quero que o asistente recorde a miña lista da compra sen celebrar un fallo comprándoa dúas veces.

### Que migra SvelteKit 3 por ti?

3:30 SvelteKit 3 tamén aterrou o xoves, movendo a configuración a Vite e substituíndo $lib por #lib, usando importacións de subcaminos de paquetes estándar. O comando de migración reescribe o que pode e deixa unha lista de tarefas pendentes para o resto. O teu robot pode axudar, e o teu diff aínda merece ser lido. O anuncio incluso recruta os teus amigos robots para os restos. Estamos chegando ao punto no que unha actualización de framework envía deberes e un profesor substituto suxerido. E as funcións remotas aínda necesitan Async Svelte experimental.

3:56 Un número de versión principal séntese tranquilizador, pero as características individuais levan as súas propias etiquetas de madurez. Comproba as que estás usando realmente.

### Que proba a excepción de GitHub en funcionamento?

4:03 Entón, quen está listo para o novo formato de Git? Aquí está esa excepción. Un repositorio público de GitHub que contén a charla de Brian Carlson xa devolve un nome de obxecto SHA 256 completo. Comprobe directamente o remoto público. As diapositivas da charla chaman o soporte unha vista previa privada e din que a creación de repositorios aínda está chegando. Hai progreso real detrás da sala de espera. Iso demostra que GitHub pode servir este repositorio de vista previa.

4:24 Dános cero garantías de que a creación de proxectos ordinarios ou todas as súas integracións estean listas. A excepción ten un límite de permisos. Se prefires ler isto en lugar de escoitarme dicilo, o diff chega á túa caixa de entrada todas as mañás, de balde en thedailydiff.dev, ligazón debaixo. Así que o veredito de hoxe é NEEDS REVIEW.

### Por que o meu veredito depende de toda a cadea de ferramentas?

4:40 Mantería a opción de "hash" máis forte e probaría toda a cadea de ferramentas antes de cambiar os valores predeterminados. A compatibilidade forma parte da entrega da mellora de seguridade. E esa é a diferenza por hoxe. Son Niko de Axrisi. Fusionar con responsabilidade.

## Fontes

- [Chacon](https://blog.gitbutler.com/git-3-sha-256) — blog.gitbutler.com
- [Git's official plan](https://git-scm.com/docs/BreakingChanges) — git-scm.com
- [Current interoperability](https://git-scm.com/docs/git-init) — git-scm.com
- [Transition design](https://git-scm.com/docs/hash-function-transition) — git-scm.com
- [Independent collision research](https://sha-mbles.github.io/) — sha-mbles.github.io
- [GitHub preview repository](https://github.com/bk2204/talk-rust-in-git) — github.com
- [Pi 1.0](https://earendil.com/posts/pi-1-0/) — earendil.com
- [Pi Durable](https://earendil.com/posts/pi-durable/) — earendil.com
- [SvelteKit 3](https://svelte.dev/blog/sveltekit-3-is-here) — svelte.dev
- [HN discussion](https://news.ycombinator.com/item?id=49924179) — news.ycombinator.com
