Novo Hash Predeterminado de Git – Que Significa

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?

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

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