A Git új hash alapértelmezettje – Mit jelent?

Amit ez a videó tartalmaz

• Miért tagadhatja meg két Git adattár a kommunikációt?
• Mit változtat valójában a Git 3?
• Miért cseréljük le az SHA-1-et, ha a Git észleli az ütközéseket?
• Mit mutatott a helyi kompatibilitási ellenőrzésünk?
• Mi marad meg egy összeomlás után a Pi Durable-ben?

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

Miért tagadhatja meg két Git adattár a kommunikációt?

0:00 Azt gondolná, a Git frissítése biztosítja, hogy az eszközei beszéljenek egymással. A Git tervezett új hash alapértelmezettje olyan adattárakat hoz létre, amelyek a mai régi formátummal nem tudnak kommunikálni. Ebben a videóban, miért változik? Mi romlik el? Ki van készen? Már létezik egy működő kivétel a GitHubon. Megmutatom, mit bizonyít a végén. Péntek van, október második, és ez a The Daily Diff.

0:18 Csütörtökön a GitHub társalapítója költséges hibának nevezte a Git tervezett változását. A Pi egy új ügynökkeretet adott ki, a SvelteKit pedig egy újabb migrációt. Scott Chacon segített a GitHub felépítésében és írta a Pro Git-et, így ez a panasz a házon belülről érkezik. A ház Git eszközöket is árul. Először is, a tényleges terv.

Mit változtat valójában a Git 3?

0:35 A Git három az új adattárakat alapértelmezetten SHA-256-ra állítaná, amint a könyvtárak és tárhelyszolgáltatások készen állnak a támogatására. A hivatalos dokumentum nem ad kiadási dátumot és továbbra is támogatja az SHA-1-et. A meglévő adattára nem változtat varázsütésszerűen formátumot, amikor frissíti a futtatható fájlt. Ezt érdemes megjegyezni, mielőtt a csoportos csevegés sürgősségi migrációt ütemez. A dráma egy javasolt alapértelmezett, és a határidő jelenleg üres naptár.

Miért cseréljük le az SHA-1-et, ha a Git észleli az ütközéseket?

0:58 Miért változik egyáltalán? A Git a tartalmuk hash-elésével nevezi el az objektumokat. A fájlok fákba kerülnek, és a commitok fákra és korábbi commitokra hivatkoznak. Ez biztosítja az integritást a történelem során. Változtassa meg a hash-sémát, és az objektumnevek is megváltoznak, beleértve az egyéb objektumokban tárolt hivatkozásokat is. Chacon Linus Torvaldsra, a Git alkotójára hivatkozva érvel azzal, hogy a megbízható

1:17 disztribúció számít. Ez egy történelmi álláspont, és Linus 2005-ben az SHA-1-et választotta. A biztonsági eset azóta megváltozott. A kutatók 2017-ben SHA-1 ütközéseket mutattak be, és később célzott prefix támadást mutattak be PGP identitás tanúsítványok ellen. A modern Git a megerősített SHA-1 segítségével észleli az ismert ütközési támadásokat. Fenntartói védelmet szeretnének a jövőbeli támadások ellen is, ami egy ésszerű elvárás az aláírásoktól. Chacon szerint az ökoszisztéma törvényjavaslata túl kevés biztonságot nyújt.

1:41 Azt javasolja, hogy írjanak alá egy különálló, erős ellenőrzőösszeget a fa tartalmáról, miközben megtartják a mai objektumcímzést alatta. Mi romlik el? Létrehoztam mindkét formátumot helyben, és hash-eltem ugyanazt a kis fájlt. Az egyik objektumnév negyven hexadecimális karakterből, a másik hatvannégyből áll.

Mit mutatott a helyi kompatibilitási ellenőrzésünk?

1:54 Aztán megpróbáltam lekérni közöttük. Az telepített Git-em elutasította, algoritmus-egyezés hiánya miatt, pontosan a jelenlegi hivatalos kézikönyvben leírt kompatibilitási rés. Ez az én régi telepített Git-emet használta, így a mai határvonalról tájékoztat. A kiadatlan Git három tesztjének nevezni kreatív könyvelés lenne. A migrációs munka olyan szkriptekbe nyúlik, amelyek feltételezik egy hash hosszát, és olyan rendszerekbe, amelyek objektumnevekhez kapcsolódnak. Egy történelem újra-hash-elése térképet igényel ezen identitások között.

2:19 A Git átmeneti tervezése magában foglalja ezt a térképezést és az aláíráskezelést. A megvalósításra való készenlét számít, mert egy tervezési dokumentum nem frissíti a kedvenc fejlesztőeszköze belsejében rejtőző könyvtárat. Ez az emberi költség Chacon érvelésében. Minden eszközfenntartó kap még egy kompatibilitási feladatot, miközben a felhasználók felfedezik, hogy a verziókezelőjüknek most verziókezelésre van szüksége. Egyelőre tesztelje a gazdagépét és az eszközeit, mielőtt kiválasztja az új formátumot egy projekthez. A meglévő csapatok megtarthatják a jelenlegi formátumukat, amíg az ökoszisztéma

2:44 felzárkózik. Eközben a Pi elérte az 1.0-t. Ez egy kódoló ügynök keretrendszer az Earendil-től, natív MCP támogatással a

Mi marad meg egy összeomlás után a Pi Durable-ben?

2:51 Codemode-on keresztül és szükség esetén betöltött eszközökkel. A csapat a minimalizmust tartja a lényegnek. Ha az ügynök beállítása már egy kis kormányra hasonlít, az eszközök távoltartása a prompttól, amíg szükséges, adminisztratív reformnak tűnik. Kiadták a Pi Durable-t is, egy különálló kísérleti keretrendszert. A feladatok mentési pontokat hoznak létre, így egy újraindított folyamat felveheti a befejezetlen munkát a tartós tárolóból. A kulcsfontosságú részlet az eszköz visszajátszása. Egy összeomlás miatt megszakított eszköz csak akkor fut újra, ha azt biztonságosnak nyilvánítja.

3:16 Ellenkező esetben a modellnek elmondják, hogy megszakították. Ez hasznos határ, amikor egy eszköz pénzt költhet. Azt akarom, hogy az asszisztens emlékezzen a bevásárlólistámra anélkül, hogy egy összeomlást kétszeri megvásárlással ünnepelne. A SvelteKit három is megérkezett csütörtökön, áthelyezve a konfigurációt a Vite-be és

Mit migrál Önnek a SvelteKit 3?

3:30 lecserélve a dollár jelet a hash lib-re, standard csomag alútvonal importálásokkal. A migrációs parancs átírja, amit tud, és a többihez egy teendőlistát hagy. A robotod segíthet, és a differenciád továbbra is érdemes elolvasni. A bejelentés még a robot barátaidat is beszervezi a maradékokhoz. Elérjük azt a pontot, ahol egy keretrendszer-frissítés házi feladatot és egy javasolt helyettes tanárt szállít. És a távoli funkciókhoz továbbra is kísérleti Async Svelte-re van szükség. Egy fő verziószám megnyugtató érzés, de az egyes funkciók saját

3:56 érettségi címkéket hordoznak. Ellenőrizze azokat, amelyeket ténylegesen használ. Szóval ki van készen a Git új formátumára?

Mit bizonyít a GitHub működő kivétele?

4:03 Itt van az a kivétel. Egy nyilvános GitHub adattár, amely Brian Carlson előadását tartalmazza, már egy teljes SHA-256 objektumnevet ad vissza. Közvetlenül ellenőriztem a nyilvános távoli adattárat. Az előadás diái a támogatást privát előnézetnek nevezik, és azt mondják, hogy az adattár létrehozása még folyamatban van. Tényleges haladás van a váróterem mögött. Ez bizonyítja, hogy a GitHub képes kiszolgálni ezt az előnézeti adattárat. Nulla garanciát ad arra, hogy a szokásos projektlétrehozás vagy az összes

4:24 integrációja készen áll. A kivételnek van egy engedélyhatára. Ha inkább elolvasná ezt, mint hallaná tőlem, a differenciál minden reggel megérkezik a postaládájába, ingyenesen a thedailydiff.dev címen, a link lent. Így a mai ítélet áttekintésre szorul. Megtartom az erősebb hash opciót, és az egész eszköztárat tesztelem, mielőtt megváltoztatnám az

Miért függ az ítéletem az egész eszköztártól?

4:40 alapértelmezéseket. A kompatibilitás része a biztonsági fejlesztés szállításának. És ez a mai differenciál. Niko vagyok az Axrisi-től. Felelősségteljesen egyesítsen. SHIP IT.

Források

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