{"id":148781,"date":"2025-11-18T23:12:24","date_gmt":"2025-11-18T21:12:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52"},"modified":"2025-11-18T23:12:24","modified_gmt":"2025-11-18T21:12:24","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Rilascio del sistema di controllo delle versioni Git 2.52","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo tre mesi di sviluppo, \u00e8 stata rilasciata la versione 2.52 del sistema distribuito di gestione dei testi sorgenti Git. Git si distingue per le sue elevate prestazioni e offre strumenti per lo sviluppo non lineare, basati su branching e merging. Per garantire l'integrit\u00e0 della cronologia e la resilienza ai cambiamenti retroattivi, si utilizza l'hashing implicito dell'intera cronologia nei singoli commit, insieme all'autenticazione tramite firme digitali degli sviluppatori per i singoli tag e commit. Il codice di Git \u00e8 distribuito sotto licenza GPLv2+. <\/p>\n
Rispetto alla versione precedente, nella nuova release sono stati inclusi 637 cambiamenti, realizzati con la partecipazione di 94 sviluppatori (33 hanno partecipato per la prima volta allo sviluppo di Git). Le novit\u00e0 principali (1, 2, 3): <\/p>\n
\n
\u00c8 stato aggiunto il comando «git last-modified» per visualizzare l'elenco dei file in una revisione specificata e i commit attraverso i quali sono state apportate le ultime modifiche a ciascuno di questi file. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c\n
\u00c8 stato aggiunto il comando «git repo» per eseguire operazioni relative all'estrazione di informazioni dal repository. Sono state proposte due sotto-comandi — «git repo info» e «git repo structure», che forniscono informazioni sulle impostazioni del repository e dettagli sulla struttura del repository (ad esempio, \u00e8 possibile conoscere il numero di riferimenti e oggetti nel repository). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Struttura del repository | Valore | | ——————— | —— | | * Riferimenti | | | * Conteggio | 1983 | | * Rami | 4 | | * Tag | 1125 | | * Remoti | 854 | | * Altri | 0 | | | | | * Oggetti raggiungibili | | | * Conteggio | 518955 | | * Commit | 77469 | | * Alberi | 188865 | | * Blobs | 251631 | | * Tag | 990 |\n
Nella squadra «git refs» sono state aggiunte tre sotto-comandi che unificano operazioni a basso livello su riferimenti (git for-each-ref, git show-ref, git update-ref e git pack-refs):\n
\n
«git refs optimize» — ottimizzazione del backend della memorizzazione dei riferimenti (analogamente a «git pack-refs»).\n
«git refs list» — visualizzazione dell'elenco di tutti i riferimenti (analogamente a «git for-each-ref» o «git show-ref»).\n
«git refs exists» — verifica dell'esistenza di un riferimento (equivalente a «git show-ref —exists»). <\/ul>\n
Il formato per l'esportazione o l'importazione della cronologia dei commit \u00e8 stato ampliato con la possibilit\u00e0 di gestire firme crittografiche, utilizzando identificatori di oggetti basati sia sull'algoritmo SHA-1 che su SHA-256. Nel comando «git fast-import» \u00e8 stata implementata la supporto per l'elaborazione di tag firmati analogamente ai commit firmati. Sono state aggiunte le opzioni «—signed-commits=<modalit\u00e0>» e «—signed-tags=<modalit\u00e0>» per gestire il trattamento di commit e tag firmati durante l'importazione (la modalit\u00e0 pu\u00f2 assumere valori verbatim, warn-verbatim, warn-stri, strip o abort).\n
Nel comando «git maintenance» \u00e8 stato aggiunto il supporto per la nuova strategia «geometric» («git config set maintenance.strategy geometric»), che consente di ridurre i tempi di manutenzione di grandi monorepository. Rispetto alla strategia precedentemente disponibile, che utilizza la logica del comando «git gc», la nuova strategia evita la ri-packatura di tutti gli oggetti ed esclude operazioni eccessivamente dispendiose di risorse, come la fusione di tutti i file pack (l'unione avviene in modo frazionario e senza pulizia degli oggetti eliminati quando possibile).\n
\u00c8 stato aggiunto il comando «git sparse-checkout clean» per semplificare il ripristino dello stato della directory di lavoro, rimuovendo file che non corrispondono alla nuova definizione di sparse-checkout, che non dovrebbero essere presenti nella copia locale in base alle attuali impostazioni di sparse-checkout.\n
Per semplificare la codebase e facilitare la manutenzione, \u00e8 stata eseguita una rifattorizzazione per ridurre l'uso della variabile globale the_repository.\n
\u00c8 stata ampliata l'applicazione dei filtri di Bloom, una struttura probabilistica per il controllo dell'appartenenza a un insieme, che consente di una falsa identificazione di un elemento mancante, ma esclude il passaggio di un elemento esistente. I filtri di Bloom sono ora utilizzati per accelerare la ricerca nella cronologia delle modifiche quando sono specificate maschere nei percorsi dei file, ad esempio, «foo\/bar\/*\/baz».\n
Le prestazioni del comando «git describe» sono state migliorate fino al 30%, grazie all'uso di una coda di priorit\u00e0. Nel comando «git remote rename» sono state accelerate le operazioni di rinominazione dei riferimenti. Nel comando «git ls-files» \u00e8 stata ampliata l'applicazione degli indici. \u00c8 stata notevolmente accelerata l'esecuzione del comando «git log -L», grazie all'esclusione di confronti a tre livelli eccessivi durante l'elaborazione della fusione dei commit. Sono state apportate ottimizzazioni alla libreria xdiff.\n
\u00c8 stata fornita un'opzione per l'uso di implementazioni in Rust di alcune funzioni interne, come la codifica e la decodifica di valori interi a lunghezza variabile. Per impostazione predefinita, il codice Rust non \u00e8 utilizzato e la sua attivazione richiede l'impostazione del flag di compilazione WITH_RUST. In futuro, si prevede di riscrivere componenti interni significativi di Git in Rust e di rendere Rust una delle dipendenze di compilazione obbligatorie in Git 3.0.\n
\u00c8 stato aggiornato l'elenco delle modifiche incompatibili che verranno implementate nella ramificazione Git 3.0. In Git 3.0, \u00e8 stato deciso di modificare l'impostazione init.defaultBranch al valore \"main\", cio\u00e8 nei repository creati con il comando \"git init\", il ramo predefinito si chiamer\u00e0 \"main\" e non \"master\". Si segnala inoltre il passaggio predefinito agli identificatori degli oggetti basati sull'algoritmo di hashing SHA-256 durante l'inizializzazione di nuovi repository. Per semplificare la portabilit\u00e0 tra repository con identificatori oggetti basati su hash SHA-1 e SHA-256, \u00e8 stata fornita la possibilit\u00e0 di eseguire operazioni di push e pull da un repository utilizzando un altro algoritmo di hashing. <\/ul>\n