Noul Hash Implicit al Git – Ce Înseamnă

Ce acoperă acest videoclip

• De ce două depozite Git pot refuza să comunice?
• Ce schimbă de fapt Git 3?
• De ce să înlocuiești SHA-1 dacă Git detectează coliziuni?
• Ce a arătat verificarea noastră locală de compatibilitate?
• Ce supraviețuiește unei căderi în Pi Durable?

Transcrierea tradusă

Tradus din narațiunea originală în engleză. Audio-ul și subtitrările disponibile sunt controlate de YouTube.

De ce două depozite Git pot refuza să comunice?

0:00 Ai crede că actualizarea Git menține comunicarea instrumentelor tale. Noul hash implicit planificat al Git creează depozite cu care formatul vechi de astăzi nu poate comunica. În acest videoclip, de ce să schimbi? Ce se strică? Cine este pregătit? Există deja o excepție funcțională pe GitHub. Îți voi arăta ce demonstrează la final. Este vineri, 2 octombrie, și acesta este The Daily Diff.

0:18 Joi, un cofondator GitHub a numit schimbarea planificată a Git o eroare costisitoare. Pi a livrat un nou agent harness, iar SvelteKit a livrat o altă migrare. Scott Chacon a ajutat la construirea GitHub și a scris Pro Git, așa că această plângere vine din interiorul casei. Casa vinde și instrumente Git. În primul rând, planul real.

Ce schimbă de fapt Git 3?

0:35 Git trei ar seta implicit depozitele noi la SHA două sute cincizeci și șase, odată ce bibliotecile și serviciile de găzduire sunt pregătite să le suporte. Documentul oficial nu specifică o dată de lansare și menține suportul SHA one. Depozitul tău existent nu își schimbă magic formatul când actualizezi executabilul. Merită reținut acest lucru înainte ca chatul de grup să programeze o migrare de urgență. Drama este un implicit propus, iar termenul limită este în prezent un calendar gol.

De ce să înlocuiești SHA-1 dacă Git detectează coliziuni?

0:58 De ce să schimbi deloc? Git numește obiectele prin hash-uirea conținutului lor. Fișierele se introduc în arbore, iar commit-urile se referă la arbore și la commit-urile anterioare. Asta îți oferă integritate pe tot parcursul istoricului. Schimbă schema de hash-uire și numele obiectelor se schimbă și ele, inclusiv referințele stocate în interiorul altor obiecte. Chacon se întoarce la Linus Torvalds, creatorul Git, susținând că distribuția de încredere

1:17 contează. Aceasta este o poziție istorică, iar Linus a ales SHA one înapoi în două mii cinci. Cazul de securitate s-a schimbat de atunci. Cercetătorii au demonstrat coliziuni SHA one în două mii șaptesprezece, și ulterior au demonstrat un atac cu prefix ales împotriva certificatelor de identitate PGP. Git modern detectează atacuri de coliziune cunoscute cu SHA one întărit. Membrii echipei de întreținere doresc protecție și împotriva atacurilor viitoare, ceea ce este o dorință rezonabilă de la semnături.

1:41 Chacon crede că nota de plată a ecosistemului cumpără prea puțină securitate. El propune semnarea unei sume de control puternice separate a conținutului arborelui, menținând în același timp adresarea obiectelor de astăzi dedesubt. Ce se strică? Am creat ambele formate local și am hash-uit același fișier mic.

Ce a arătat verificarea noastră locală de compatibilitate?

1:54 Un nume de obiect are patruzeci de caractere hexadecimale, celălalt are șaizeci și patru. Apoi am încercat să le extrag între ele. Git-ul meu instalat a respins-o cu algoritmi neconcordanți, exact decalajul de compatibilitate descris în manualul oficial curent. Acesta a folosit vechiul meu Git instalat, așa că ne spune despre limita de astăzi. A-l numi un test al Git trei nelansat ar fi o contabilitate creativă. Lucrarea de migrare ajunge la scripturi care presupun lungimea unui hash, și sisteme care se leagă la numele obiectelor.

2:19 Re-hash-uirea unui istoric necesită o mapare între acele identități. Designul de tranziție al Git include acea mapare și gestionarea semnăturilor. Disponibilitatea implementării contează, deoarece un document de proiectare nu actualizează biblioteca ascunsă în interiorul instrumentului tău favorit de dezvoltare. Acesta este costul uman din argumentul lui Chacon. Fiecare întreținător de instrumente primește o altă sarcină de compatibilitate, în timp ce utilizatorii descoperă că sistemul lor de control al versiunilor necesită acum control al versiunilor. Deocamdată, testează-ți gazda și instrumentele înainte de a alege noul format pentru un

2:44 proiect. Echipele existente își pot păstra formatul actual în timp ce ecosistemul recuperează. Între timp, Pi a ajuns la un punct zero.

Ce supraviețuiește unei căderi în Pi Durable?

2:51 Este un agent de codificare de la Earendil, cu suport nativ MCP prin Codemode și instrumente încărcate atunci când sunt necesare. Echipa numește minimalismul punctul cheie. Dacă setarea agentului tău seamănă deja cu un mic guvern, ținerea instrumentelor în afara promptului până la nevoie sună ca o reformă administrativă. A lansat și Pi Durable, un framework experimental separat. Sarcinile salvează puncte de control, astfel încât un proces repornit să poată prelua munca neterminată din stocarea persistentă. Detaliul crucial este reluarea instrumentelor.

3:16 Un instrument întrerupt de o cădere se reexecută numai atunci când declară că este sigur. În caz contrar, modelului i se spune că a fost întrerupt. Aceasta este o limită utilă atunci când un instrument poate cheltui bani. Vreau ca asistentul să-și amintească lista mea de cumpărături fără să sărbătorească o cădere prin cumpărarea ei de două ori.

Ce migrează SvelteKit 3 pentru tine?

3:30 SvelteKit trei a sosit și joi, mutând configurația în Vite și înlocuind dollar lib cu hash lib, folosind importuri standard de subcai de pachet. Comanda de migrare rescrie ceea ce poate și lasă o listă de sarcini pentru restul. Robotul tău te poate ajuta, iar diff-ul tău merită citit. Anunțul chiar recrutează prietenii tăi roboți pentru restul. Ajungem în punctul în care o actualizare de framework livrează teme și un profesor suplinitor sugerat. Și funcțiile la distanță necesită încă Async Svelte experimental.

3:56 Un număr de versiune majoră pare reconfortant, dar funcțiile individuale poartă propriile etichete de maturitate. Verifică-le pe cele pe care le utilizezi de fapt.

Ce demonstrează excepția funcțională a GitHub?

4:03 Deci cine este pregătit pentru noul format al Git? Iată excepția aceea. Un depozit public GitHub care conține prezentarea lui Brian Carlson returnează deja un nume complet de obiect SHA două sute cincizeci și șase. Am verificat direct remote-ul public. Slide-urile prezentării numesc suportul o previzualizare privată și spun că crearea depozitului este încă în curs. Există progrese reale în spatele sălii de așteptare. Asta demonstrează că GitHub poate servi acest depozit de previzualizare.

4:24 Nu ne oferă nicio garanție că crearea obișnuită a proiectelor sau toate integrările tale sunt gata. Excepția are o limită de permisiuni. Dacă preferi să citești asta decât să mă auzi spunând-o, diff-ul ajunge în căsuța ta poștală în fiecare dimineață, gratuit la the daily diff dot dev, link mai jos. Deci verdictul de astăzi este NEEDS REVIEW.

De ce verdictul meu depinde de întregul lanț de instrumente?

4:40 Aș păstra opțiunea de hash mai puternică și aș testa întregul lanț de instrumente înainte de a schimba setările implicite. Compatibilitatea face parte din livrarea îmbunătățirii de securitate. Și acesta este diff-ul pentru astăzi. Sunt Niko de la Axrisi. Îmbină responsabil.

Surse

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