A Git forráskód-kezelő rendszer 2.51 verziójának kiadása

Két hónapos fejlesztés után megjelent a Git 2.51 kiosztott rendszer forráskód-kezelője. A Git magas teljesítménnyel rendelkezik, és eszközöket kínál a nem lineáris fejlesztéshez, amely az ágak elágazásán és egyesítésén alapul. A történelem integritásának és a "visszamenőleges" változtatásokkal szembeni ellenállónak biztosításához implicit hash-elést használnak az összes korábbi történetben minden egyes elkötelezésnél, valamint digitális aláírásokat alkalmaznak a fejlesztők által egyes címkék és elkötelezések hitelesítésére. A Git kódja GPLv2+ licenc alatt terjesztésre kerül.

A korábbi kiadással összehasonlítva az új verzióba 506 módosítást fogadtak el, 91 fejlesztő közreműködésével (21 fejlesztő először vett részt a Git fejlesztésében). Fő újítások (1, 2, 3):

  • Jelentősen megnövekedett a 'git push' és 'git fetch' parancsok teljesítménye olyan repository-kban, ahol nagyszámú hivatkozás található. A gyorsítás a hivatkozások csoportos frissítésének köszönhető, amely lehetővé teszi, hogy egy tranzakcióban több hivatkozást kezeljünk, ahelyett, hogy minden egyes hivatkozás frissítéséhez külön tranzakciót hoznánk létre. Az optimalizálás jelentősen növelte a 'reftable' backend teljesítményét, amely most már gyorsabb a 'files' backendnél. Például egy olyan teszt repository-ban, ahol 10 ezer hivatkozás található, a 'git fetch' teljesítménye a 'reftable' backend használatával 22-szeresére nőtt, míg a 'files' backend használatával 1,25-szörös növekedést mutatott. A 'git push' esetében a növekedés 18 és 1,21-szeres volt, megfelelőszerint.
  • Javasoltak egy új módszert a pack fájlokban a repository olyan részeinek csomagolására, amelyek nem kapcsolódnak az elérhetetlen objektumok nyomon követéséhez, amelyekre a repository-ban hivatkozások nem léteznek (belső ágak vagy címkék nem hivatkoznak rájuk). Az elérhetetlen objektumokra vonatkozó információk külön pack fájlokban ('cruft packs') tárolódnak, ami szükségessé tette azok tükrözését a többpack indexekben (MIDX - multi-pack index), hogy azok az objektumok is szerepeljenek, amelyek kezdetben elérhetetlenek voltak és csak a cruft packban tárolódtak, de később elérhetővé váltak egy hivatkozó elkötelezés után.

    Az új verzióban a pack-fájlok újrapakolásakor biztosított a további másolatok megőrzése, amelyeket a csak cruft-fájlokban tárolt elérhető objektumok tartalmaznak. Ez a módosítás garantálja, hogy az elérhető objektumok tárolására használt pack-fájlok sorozatában nincsenek olyan objektumok, amelyek más, ezen sorozaton kívül tárolt objektumokra hivatkoznak. A cruft-fájlokból származó elérhetetlen tartalom kizárására a többpackos indexekből (MIDX) felajánlott „repack.MIDXMustContainCruft” beállítás jelentősen csökkenti az ilyen indexek méretét. A beállítás aktiválása a GitHub tárolóban 38%-kal csökkentette a MIDX-indexek méretét, 35%-kal felgyorsította a MIDX-indexek írását, és 5%-kal javította az olvasási teljesítményt.

  • A git pack-objects parancshoz hozzáadódott a „—path-walk” opció, amely egy új módszert vezet be az objektumok információinak gyűjtésére a pack-fájlok újrapakolásakor. Ahelyett, hogy az objektumok a revíziók sorrendjében lennének bejárva, a „—path-walk” üzemmód használatakor az objektumokat a fájlutak bejárásán keresztül sorolják be, lehetővé téve, hogy egy csapásra csomagolják az összes objektumot ugyanazon fájlúttal. Ez a megközelítés lehetőséget ad arra, hogy elkerüljük a heurisztikát, amely a hash-álírt használja az objektum és a fájlút közötti kapcsolat meghatározására, valamint megszabaduljak az objektumok csomagolás előtti rendezésétől. A „—path-walk” üzemmódban használt generált pack-fájlok mérete lényegesen kisebb, mint a hash-alapú objektumcsoportosítás esetén.
  • Kijelölésre került egy formátum a munkaállapotok és indexek tárolt állapotainak cseréjére, amelyeket a git stash parancs segítségével hoztak létre. Az új formátum lehetővé teszi, hogy a mentett változásokat (stash-bejegyzések) commitok sorozataként kódolják. Az importáláshoz és exportáláshoz a „git stash import” és „git stash export” almennyiségek állnak rendelkezésre, amelyeket a mentett állapotok egyik rendszerből a másikba való átvitelére és a push vagy pull műveletek elvégzésére használhatunk, így azok szokásos ágakként vagy tagekként működnek. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
  • A «git cat-file» parancs, amely a megadott objektumok tartalmát jeleníti meg, lehetőséget biztosít a hiányzó objektumok (például a tároló megsérülése miatt) és a szubmodulok információinak megjelenítésére a «—batch» és «—batch-check» opciók használatakor. Korábban a szubmodul útvonalának megadásakor a «git cat-file —batch-check» parancs «hiányzik» üzenetet adott, most pedig az objektum azonosítóját fogja megmutatni.
  • A «git log» parancsnál Bloom-filter alapú optimalizációk vannak alkalmazva a változások történetének gyorsítására, ha több fájlúttal rendelkező szűrőket adnak meg, például «git log — path/to/a path/to/b».
  • A «git switch» és «git restore» parancsok stabilizálva lettek, amelyeket 2019 óta kísérleti jelleggel használtak. Ezek a parancsok a «git checkout» modern megfelelőiként kerülnek bemutatásra, amelyek elválasztják a parancs kiszolgáló, például az ágak manipulálása (váltás és létrehozás) és a fájlok visszaállítása a munkakönyvtárban.
  • A Git 3.0 ágban a «git whatchanged» parancs elavultnak lett nyilvánítva és törlésre kerül, amely a «git log —raw» megfelelője.
  • A «git for-each-ref» parancshoz hozzá lett adva a «—start-after» opció, amely együtt használható a «—count» opcióval az oldali kimenet szervezésére.
  • A «git merge» és «git pull» parancsokhoz hozzá lett adva a «—compact-summary» opció, amely a változások tömör összefoglaló formátumának használatát teszi lehetővé a diffstat formátum helyett.
  • A Git kódalapjában lehetővé vált a «bool» kulcsszó használata, amely a C99 szabványban jelent meg. Néhány C99 képesség, amely kísérleti jelleggel került használatra a Gitben, szintén dokumentálva van (például 2026 közepén tervezik az «(struct foo){ .member = value };» szerkezetek alkalmazásának engedélyezését). A Githez 2021-től kötelező a C99-t támogató fordító, de a C99 specifikáció képességei rendkívül óvatosan kerülnek bevezetésre, hogy megőrizzék a kompatibilitást a részben támogató fordítókkal.
  • A patch-ek elfogadási szabályaiba módosításokat vezettek be, amelyek lehetővé teszik a patch-ek beküldését álnevet használva, nem csak a fejlesztő valódi nevével. Ez a változás összhangban áll a Linux Kernel patch elfogadási szabályaival.
  • Frissítve lett a Git 3.0 branchben végrehajtott, kompatibilitást sértő változások listája. A Git 3.0 közelgő kiadásában jelentős változás, hogy az új tárolók inicializálásakor alapértelmezés szerint a SHA-256 hash algoritmus alapú objektumazonosítókat használják, valamint a „reftable” formátumot alkalmazzák a tárolóban lévő ágakra és címkékre való hivatkozások tárolására (ez a JGit projekt blokkalapú tárolását használja, amelyet nagyon nagy számú hivatkozás tárolására optimalizáltak).

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster