Mi újság a Git 2.55.0-ban?

A Git projekt nemrégiben kiadta a Git 2.55.0-t. Nézzük meg ennek a kiadásnak néhány figyelemre méltó kiemelését, amelyek a GitLab Git csapatának hozzájárulásait is tartalmazzák. Ami szóba kerül: a git-history(1) megtanulja a fixup fsmonitor démon használatát Linuxon, git push egy távoli csoporthoz, a git log --graph lane szélességének korlátozása, a Rust fejlődése a Git kódalapban, gyorsabb git-grep(1) és git-cherry(1) részleges klónokban. A git-history(1) megtanulja a fixup funkciót. A Git 2.54.0-ás kiadásának kiemelései között szerepelt a git-history(1) bevezetése. A 2.55.0-ban ehhez az eszközhöz egy új alművelet került hozzáadásra: fixup. Képzeld el, hogy változtatásokat hajtottál végre, és ezeket egy meglévő elkötelezettségbe szeretnéd beilleszteni. A leggyakoribb megközelítés ennek megvalósítására egy fixup elkötelezettség létrehozása és annak automatikus beolvasása a git-rebase(1) segítségével: git commit --fixup=<commit-id> git rebase -i --autosquash <commit-id>^ Ezt két lépésben megtenni ügyetlen, különösen azért, mert interaktív rebaset igényel. Ehelyett használhatod a git-history(1) fixup parancsot: git history fixup <commit-id> Ez a lépett módosításokat a megadott elkötelezettségbe illeszti. További bónuszként, mivel a git-history(1)-t használod, minden más helyi ágazat, amely tartalmazza a módosított elkötelezettséget, frissül. Tehát amikor egymásra épülő ágakkal dolgozol, egy elkötelezettség fixup-ja a veremben automatikusan rebase-eli az összes kapcsolódó ágat. Ezt a funkciót Patrick Steinhardt valósította meg. fsmonitor démon Linuxra Nagy monorepo-k kezelésekor a git-status(1) lassú lehet a helyi munkafolyamatban történt változások meghatározásában, mert a Git-nek végig kell járnia az egész munkafát, hogy lássa, mely fájlok módosultak. Ennek a folyamatnak a felgyorsítására 2018 januárjában egy core.fsmonitor beállítás került bevezetésre a Git 2.16-ban. Akkoriban saját eszközt kellett biztosítani (mint például a Watchman). Amikor ezt beállították, ez az eszköz a háttérben fut, és figyeli a fájlrendszeren bekövetkező változásokat. Ez értesíti a Git-et, hogy egy fájl érintett volt, majd a Git ellenőrzi, hogy a fájl módosult-e, és frissíti a gyorsítótárazott állapotot. Ezért amikor a felhasználó meghívja a git-status(1)-et, az egyszerűen visszaadhatja a gyorsítótárazott állapotot. 2022 áprilisában a core.fsmonitor beállítást megváltoztatták, hogy egy logikai értéket fogadjon el. Ha ez a beállítás igazra van állítva, egy Git-be épített démon használatos, és nincs szükség harmadik féltől származó eszközre. De ez a fájlrendszer figyelő csak Windowsra és macOS-re került implementálásra, a GNU/Linux támogatás még nem létezett. A Git 2.55-ös verzióval ez a helyzet is megváltozott, Linux támogatását is hozzáadták. Ennek eléréséhez az inotify(7) került felhasználásra. Az inotify(7) a fanotify(7) helyett lett választva, mert a fanotify(7) emelt szintű jogosultságokat igényel. Van ennek egy kis hátránya is, a fsmonitor-nak figyelőt kell elhelyeznie a repó minden egyes könyvtárában. Egy nagy repó esetében elérheted az inotify megfigyelések (fs.inotify.max_user_watches) határát, amit esetleg emelned kell. Ezeket a változtatásokat Paul Tarjan terjesztette be Eric DeCosta és Marziyeh Esipreh munkája alapján. git push egy távoli csoporthoz Már régóta a git-fetch(1) megtanulta, hogy egy csoport távoli helyről hozzon le. A következő parancs egy távoli csoportot állít be: git config set remotes.forks "origin upstream" Ha ezt beállították, a "forks" csoportra lehet git-fetch(1)-t végrehajtani, és ekkor az abban a listában szereplő összes távoli helyről le lesz hozva az adat. Ez hasznos lehet, ha az összes távoli helyről egyszerre akarod megkapni a frissítéseket. A git-push(1), azonban, nem tudta használni a távoli csoportokat. A Git 2.55-ben ez a rés megoldódik, és a git-push(1) most már elfogad távoli csoportokat is. Például, ha a főágat szeretnéd a fenti csoportba tolni: git push forks main Hasonlóan a git-fetch(1)-hez, ez a parancs a megadott ref-eket tolja a csoport minden távoli helyére. Minden távoli hely függetlenül van tolva, és tiszteletben tartja a saját remote.<name>.push leképezését és másolási beállításait. Ezt a funkciót Usman Akinyemi terjesztette be, Junio C Hamano javasolta. A git log --graph lane szélességének korlátozása A git-log(1) --graph opciója egy ASCII ábrázolását rajzolja a elkötelezettségek történetének. Egy olyan repóban, ahol sok aktív hozzájáruló dolgozik, ez a grafikon nagyon szélesre nőhet. Például, a git.git repóban ez a grafikon kilenc sáv szélesre nő már 30 elkötelezettség után: * 26d8d94e94 Néhány további téma a -rc2 előtt * 02bb39c5cb Újra összevonni az 'js/objects-larger-than-4gb-on-windows-more' ágat |\ | * c6a4629e32 odb: használj size_t típusú object_info.sizep és a méret API-k | * 7a3a78cc76 packfile, delta: dobd el a `cast_size_t_to_ulong()` burkolókat | * 188bac14f7 pack-objects: használj size_t típusú in-core objektum méreteket | * 2d83cc3f84 packfile: szélesebbé tedd az unpack_entry() méret kimeneti paraméterét size_t-ra | * 1d43315b31 pack-objects(check_pack_inflate()): használj size_t-ot unsigned long helyett | * 33afe87338 patch-delta: használj size_t-ot a méretekhez | * 8ea69373a4 compat/msvc: használj _chsize_s-t a ftruncate-hoz * | 8cf57cbec4 Újra összevonni az 'kw/gitattributes-typofix' ágat |\ \ | * | 0bf506efd4 gitattributes: javítsd az eol attribútumot a Perl szkriptekhez * | | 8d96f09e92 Újra összevonni az 'js/objects-larger-than-4gb-on-windows' ágat |\ \ \ | * | | ab3810eb6f zlib: megfelelően klampold meg a uLong-ot * | | | 95e20213fa Remélhetőleg végső adag a -rc2 előtt * | | | 8632b5c49d Újra összevonni az 'en/commit-graph-timestamp-fix' ágat |\ \ \ \ | * | | | fbcc5408fc commit-graph: használj timestamp_t-t a max szülő generációs akkumulátorhoz * | | | | 619931f561 Újra összevonni az 'dl/posix-unused-warning-clang' ágat |\ \ \ \ \ | * | | | | cf48887610 compat/posix.h: egyszerűsítsd a GIT_GNUC_PREREQ() összehasonlítást | * | | | | ffd45926dc compat/posix.h: tisztítsd meg a GIT_GNUC_PREREQ()-t és az UNUSED-t | * | | | | 689dc92e50 compat/posix.h: engedélyezd az UNUSED figyelmeztető üzeneteket Clang számára * | | | | | 621962aa7a Újra összevonni az 'td/ls-files-pathspec-prefilter' ágat |\ \ \ \ \ \ | * | | | | | 3f5203eeb4 ls-files: szűrd a pathspec-t lstat előtt | | |_|_|_|/ | |/| | | | * | | | | | 0c706d5092 Újra összevonni az 'ta/doc-config-adoc-fixes' ágat |\ \ \ \ \ \ | * | | | | | 4fa2c6e045 doc: git-config: escape hibás highlight markup | * | | | | | 042221cccb doc: config/sideband: javítsd a leírás lista elválasztót | * | | | | | 3eb61fda62 doc: config: zárd le a vándorló listákat * | | | | | | 49cb068fb2 Újra összevonni az 'jc/t1400-fifo-cleanup' ágat |\ \ \ \ \ \ \ | * | | | | | | e8f12e0e95 t1400: tedd, hogy a fifo teszt tisztán végezze el * | | | | | | | b4970f8448 Újra összevonni az 'td/describe-tag-iteration' ágat |\ \ \ \ \ \ \ \ | * | | | | | | | 55088ac8a4 describe: korlátozd a default ref iterációt a tagekre Ez azért történik, mert minden sáv lefelé halad arra az elkötelezettségre, ahonnan az ágat létrehozták. Ez a commit üzeneteket a jobb oldalra tolja, megnehezítve az olvasást. Különösen amikor elérjük a terminál képernyő szélességét, ez használhatatlanná válik. A Git 2.55 új --graph-lane-limit=<n> opciót ad hozzá, hogy korlátozza a megrajzolt sávok számát. Minden sáv, amely meghaladja a határt, ~ truncaáló jelzéssel van helyettesítve, így nyilvánvaló marad, hogy a grafikon ki lett vágva: git log --graph --graph-lane-limit=5 Ezt az opciót használva a ugyanazt a 30 elkötelezettséget, mint fent, a következőt kapjuk: * 26d8d94e94 Néhány további téma a -rc2 előtt * 02bb39c5cb Újra összevonni az 'js/objects-larger-than-4gb-on-windows-more' ágat |\ | * c6a4629e32 odb: használj size_t-t az object_info.sizep-hoz és a méret API-khoz | * 7a3a78cc76 packfile,delta: dobd el a `cast_size_t_to_ulong()` burkolókat | * 188bac14f7 pack-objects: használj size_t-t az in-core objektum méretekhez | * 2d83cc3f84 packfile: szélesebb méretű unpack_entry() kimeneti paraméter size_t-ra | * 1d43315b31 pack-objects(check_pack_inflate()): használj size_t-t unsigned long helyett | * 33afe87338 patch-delta: használj size_t-t a méretekhez | * 8ea69373a4 compat/msvc: használj _chsize_s-t a ftruncate-hoz * | 8cf57cbec4 Újra összevonni az 'kw/gitattributes-typofix' ágat |\ \ | * | 0bf506efd4 gitattributes: javítsd az eol attribútumot a Perl szkriptekhez * | | 8d96f09e92 Újra összevonni az 'js/objects-larger-than-4gb-on-windows' ágat |\ \ \ | * | | ab3810eb6f zlib: megfelelően klampold meg a uLong-ot * | | | 95e20213fa Remélhetőleg végső adag a -rc2 előtt * | | | 8632b5c49d Újra összevonni az 'en/commit-graph-timestamp-fix' ágat |\ \ \ \ | * | | | fbcc5408fc commit-graph: használj timestamp_t-t a max szülő generációs akkumulátorhoz * | | | | 619931f561 Újra összevonni az 'dl/posix-unused-warning-clang' ágat |\ \ \ \ \ | * | | | ~ cf48887610 compat/posix.h: egyszerűsítsd a GIT_GNUC_PREREQ() összehasonlítást | * | | | ~ ffd45926dc compat/posix.h: tisztítsd meg a GIT_GNUC_PREREQ()-t és az UNUSED-t | * | | | ~ 689dc92e50 compat/posix.h: engedélyezd az UNUSED figyelmeztető üzeneteket Clang számára * | | | | ~ 621962aa7a Újra összevonni az 'td/ls-files-pathspec-prefilter' ágat |\ \ \ \ \~ | * | | | ~ 3f5203eeb4 ls-files: szűrd a pathspec-t lstat előtt | | |_|_|_~ | |/| | | ~ * | | | | ~ 0c706d5092 Újra összevonni az 'ta/doc-config-adoc-fixes' ágat |\ \ \ \ \~ | * | | | ~ 4fa2c6e045 doc: git-config: escape hibás highlight markup | * | | | ~ 042221cccb doc: config/sideband: javítsd a leírás lista elválasztót | * | | | ~ 3eb61fda62 doc: config: zárd le a vándorló listákat * | | | | ~ 49cb068fb2 Újra összevonni az 'jc/t1400-fifo-cleanup' ágat |\ \ \ \ \~ | * | | | ~ e8f12e0e95 t1400: tedd, hogy a fifo teszt tisztán végezze el * | | | | ~ b4970f8448 Újra összevonni az 'td/describe-tag-iteration' ágat |\ \ \ \ \~ | * | | | ~ 55088ac8a4 describe: korlátozd a default ref iterációt a tagekre Az opció csak a --graph-al együtt érdemes. Az alapértelmezett érték 0, ami korlátozás nélküli állapotot jelent, és a nulla vagy negatív értékek ugyanolyan módon kerülnek kezelésre, mint a --max-parents parancs. Ezt a funkciót Pablo Sabater terjesztette be. A Rust fejlődése a Git kódalapban 2025 márciusában, a Git 2.49 kiadásával az első Rust kód került a Git kódalapba. Rust kötéseket adtak hozzá, hogy a Rust kód hívhassa a libgit-et. De ezek a Rust kódok nem voltak felhasználva a Git binárisokban. 2025 novemberében, a Git 2.52-ben bevezetésre került az első Rust produktív kód a Git-be. Ezután egy Rust implementáció került hozzáadásra a varint alrendszerhez. Ez a kód opcióként le van fordítva, ha elérhető a Rust fordító, és amikor nem, a C implementációt használják. Ezt teszt ballonként adták hozzá a forgalmazók részére, hogy kezdjék el felkészíteni eszközeiket egy olyan Git kiadásra, amely idővel Rust-ot igényel. Az idén, a 2.54 verzióban további Rust kódokat adtak hozzá a kód alaphoz az ObjectID típus bevezetésével. Ezt a SHA-1 és SHA-256 közötti interoperabilitás megvalósítása érdekében tett erőfeszítések részeként adták hozzá. Eddig a kiadásig mind a Make, mind a Meson build rendszerek kedvesen visszaestek a C implementációra, ha a Rust fordító nem található. Ezzel a v2.55-ös kiadással viszont a Rust fordító kötelező, hacsak nem tiltod le kifejezetten a build rendszerben. Kérlek, vedd figyelembe, hogy ez nem érinti a Git felhasználóit. Ez csak azokat érinti, akik forrásból építik a Git-et. Ha a Git-et fordítod, és nem akarod használni a Rust-ot, tiltsd le az alábbi parancsok egyikével: # Meson meson configure -Drust=disabled # Makefile make NO_RUST=YesPlease A Rust integrálása a Git-be folyamatos (és befejezetlen), több kiadást magába foglaló közösségi erőfeszítés. Ezt lehetetlen egyetlen személynek tulajdonítani, de néhány a legkiemelkedőbb hozzájárulók közé tartozik brian m. carlson, Patrick Steinhardt, Ezekiel Newren és Calvin Wan. Gyorsabb git-grep(1) és git-cherry(1) részleges klónokban a git-clone(1) rendelkezik ezzel a részleges klón nevű funkcióval. Ez lehetővé teszi a felhasználó számára, hogy szűrőt alkalmazzon arra, amit a szerverről küldenek. A gyakorlatban ezt a --filter opción keresztül végzik. Például: git clone --filter=blob:none <remote> Ez a repót klónozza, de ez a klón kizárja az összes blobot (azaz a fájlok tartalmát a fán). Ez jelentősen felgyorsíthatja a klónozást, de cserébe a Git-nek később le kell töltenie a blobokat, amikor más parancsokat használnak, amelyek a fájlok tartalmát olvassák. És egyes parancsoknak sok hiányzó blobra lehet szüksége. A git-grep(1) az egyik ilyen parancs, mivel a fájlok tartalmát keresi. Ehhez nyilvánvalóan szüksége van ezekre a fájlokra. Képzeld el, hogy a "TODO" szót szeretnéd keresni 100 elkötelezettségnyire a múltban: git grep TODO HEAD~100 Ez a parancs a HEAD~100 elkötelezettséget és a hozzá tartozó fákat oldja meg. De ezek a fák olyan blobokhoz mutathatnak, amelyek még nincsenek letöltve. Korábban minden blob külön töltődött le. De ez a Git 2.55-ös verziójában javult. A Git ezen verziójában a blob letöltéseket egyetlen tárgyalási körbe csoportosítják, amely a szerverhez megy. Ez a csoportosítás mostantól implementálva van mind a git-grep(1), mind a git-cherry(1) esetében. Ezt a változást Elijah Newren terjesztette be. További olvasmány Ez a cikk csak néhányat emelt ki a GitLab és a szélesebb Git közösség által tett hozzájárulások közül az utolsó kiadás során. További információkat a Git projekt hivatalos kiadási bejelentéséből kaphatsz. Nézd meg korábbi Git kiadási blogbejegyzéseinket is, hogy láthasd a GitLab csapatának korábbi hozzájárulásait.