Git's Nieuwe Hash Standaard – Wat Het Betekent

Wat deze video behandelt

• Waarom kunnen twee Git-repositories weigeren te communiceren?
• Wat verandert Git 3 eigenlijk?
• Waarom SHA-1 vervangen als Git botsingen detecteert?
• Wat toonde onze lokale compatibiliteitscontrole?
• Wat overleeft een crash in Pi Durable?

Vertaald transcript

Vertaald vanuit de originele Engelse gesproken tekst. Beschikbare audio en ondertiteling worden beheerd door YouTube.

Waarom kunnen twee Git-repositories weigeren te communiceren?

0:00 Je zou denken dat het upgraden van Git ervoor zorgt dat je tools blijven communiceren. Git's geplande nieuwe hash-standaard creëert repositories die het oude formaat van vandaag niet kunnen aanspreken. In deze video, waarom veranderen? Wat gaat er kapot? Wie is er klaar voor? Er is al een werkende uitzondering op GitHub. Ik zal je aan het einde laten zien wat het bewijst. Het is vrijdag, twee oktober, en dit is The Daily Diff.

0:18 Donderdag noemde een medeoprichter van GitHub de geplande verandering van Git een dure fout. Pi leverde een nieuwe agent harness, en SvelteKit leverde nog een migratie. Scott Chacon hielp GitHub bouwen en schreef Pro Git, dus deze klacht komt van binnenuit. Het huis verkoopt ook Git-tools. Ten eerste, het eigenlijke plan.

Wat verandert Git 3 eigenlijk?

0:35 Git drie zou standaard nieuwe repositories naar SHA twee vijf zes instellen, zodra bibliotheken en hostingdiensten klaar zijn om het te ondersteunen. Het officiële document geeft geen releasedatum en blijft SHA één ondersteunen. Je bestaande repository verandert niet magisch van formaat wanneer je de uitvoerbare bestand upgrade. Dat is de moeite waard om te onthouden voordat je groepschat een noodmigratie plant. Het drama is een voorgestelde standaard, en de deadline is momenteel een lege kalender.

Waarom SHA-1 vervangen als Git botsingen detecteert?

0:58 Waarom überhaupt veranderen? Git benoemt objecten door hun inhoud te hashen. Bestanden voeden trees, en commits verwijzen naar trees en eerdere commits. Dat geeft je integriteit over de hele geschiedenis. Verander het hashing-schema en objectnamen veranderen ook, inclusief de referenties die in andere objecten zijn opgeslagen. Chacon verwijst naar Linus Torvalds, de maker van Git, met het argument dat betrouwbare

1:17 distributie ertoe doet. Dat is een historisch standpunt, en Linus koos SHA één in tweeduizend vijf. De beveiligingssituatie is sindsdien verschoven. Onderzoekers demonstreerden SHA één botsingen in tweeduizend zeventien, en demonstreerden later een gekozen prefix-aanval tegen PGP-identiteitscertificaten. Moderne Git detecteert bekende botsingsaanvallen met verharde SHA één. De beheerders willen ook bescherming tegen toekomstige aanvallen, wat een redelijke eis is van handtekeningen.

1:41 Chacon denkt dat de kosten voor het ecosysteem te weinig beveiliging opleveren. Hij stelt voor om een aparte sterke checksum van de boominhoud te ondertekenen, terwijl de huidige objectadressering behouden blijft. Wat gaat er kapot? Ik creëerde beide formaten lokaal en hashte hetzelfde kleine bestandje.

Wat toonde onze lokale compatibiliteitscontrole?

1:54 De ene objectnaam heeft veertig hex-tekens, de andere heeft vierenzestig. Daarna probeerde ik ertussen te fetchen. Mijn geïnstalleerde Git weigerde het met niet-overeenkomende algoritmes, precies de compatibiliteitskloof beschreven in de huidige officiële handleiding. Dit gebruikte mijn oude geïnstalleerde Git, dus het vertelt ons over de grens van vandaag. Het een test van de niet-uitgebrachte Git drie noemen, zou creatief boekhouden zijn. De migratiewerkzaamheden reiken tot in scripts die uitgaan van een hash-lengte, en systemen die linken naar objectnamen.

2:19 Het opnieuw hashen van een geschiedenis vereist een mapping tussen die identiteiten. Git's transitieontwerp omvat die mapping en de afhandeling van handtekeningen. Implementatiebereidheid is belangrijk, omdat een ontwerpdokument de bibliotheek die verborgen zit in je favoriete ontwikkelaarstool niet upgrade. Dat is de menselijke prijs in Chacóns argument. Elke toolbeheerder krijgt er nog een compatibiliteitsklus bij, terwijl gebruikers ontdekken dat hun versiebeheer nu versiebeheer nodig heeft. Test voorlopig je host en tooling voordat je het nieuwe formaat kiest voor een

2:44 project. Bestaande teams kunnen hun huidige formaat behouden terwijl dat ecosysteem inhaalt. Ondertussen bereikte Pi één punt nul.

Wat overleeft een crash in Pi Durable?

2:51 Het is een coding agent harness van Earendil, met native MCP-ondersteuning via Codemode en tools die geladen worden wanneer ze nodig zijn. Het team noemt minimalisme het doel. Als je agent-setup al lijkt op een kleine overheid, klinkt het buiten de prompt houden van tools totdat ze nodig zijn als administratieve hervorming. Het bracht ook Pi Durable uit, een apart experimenteel framework. Taken slaan checkpoints op zodat een herstart proces onafgemaakt werk kan oppakken vanuit permanente opslag. Het cruciale detail is de herhaling van tools.

3:16 Een tool die door een crash wordt onderbroken, wordt alleen opnieuw uitgevoerd wanneer deze aangeeft dat dit veilig is. Anders krijgt het model te horen dat het onderbroken is. Dat is een nuttige grens wanneer een tool geld kan uitgeven. Ik wil dat de assistent mijn boodschappenlijst onthoudt zonder een crash te vieren door het twee keer te kopen.

Wat migreert SvelteKit 3 voor u?

3:30 SvelteKit drie landde ook donderdag, met configuratie naar Vite en het vervangen van dollar lib door hash lib, met behulp van standaard package subpath imports. Het migratiecommando herschrijft wat het kan en laat een takenlijst over voor de rest. Je robot kan helpen, en je diff verdient nog steeds gelezen te worden. De aankondiging werft zelfs je robotvrienden voor de restjes. We bereiken het punt waar een framework-upgrade huiswerk en een voorgestelde invalkracht meelevert. En externe functies hebben nog steeds experimentele Async Svelte nodig.

3:56 Een hoofdversienummer voelt geruststellend, maar individuele functies dragen hun eigen rijpheidslabels. Controleer de labels van de functies die je daadwerkelijk gebruikt.

Wat bewijst GitHub's werkende uitzondering?

4:03 Dus wie is er klaar voor het nieuwe formaat van Git? Hier is die uitzondering. Een openbare GitHub-repository met Brian Carlsons lezing retourneert al een volledige SHA twee vijf zes objectnaam. Ik controleerde de openbare remote rechtstreeks. De lezing slides noemen ondersteuning een privé-preview en zeggen dat het aanmaken van repositories nog moet komen. Er is daadwerkelijke vooruitgang achter de wachtkamer. Dat bewijst dat GitHub deze preview-repository kan serveren.

4:24 Het geeft ons nul garantie dat gewone projectcreatie of al je integraties klaar zijn. De uitzondering heeft een toestemmingsgrens. Als je dit liever leest dan mij hoort zeggen, de diff landt elke ochtend in je inbox, gratis op the daily diff dot dev, link hieronder. Dus het oordeel van vandaag is 'needs review'.

Waarom hangt mijn oordeel af van de hele toolchain?

4:40 Ik zou de sterkere hash-optie behouden en de hele toolchain testen voordat ik standaarden wijzig. Compatibiliteit is onderdeel van het leveren van de beveiligingsverbetering. En dat is de diff voor vandaag. Ik ben Niko van Axrisi. Voeg verantwoordelijk samen.

Bronnen

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