{"id":108813,"date":"2023-06-02T15:10:15","date_gmt":"2023-06-02T13:10:16","guid":{"rendered":"https:\/\/prohoster.info\/?p=108813"},"modified":"2023-06-02T17:30:17","modified_gmt":"2023-06-02T15:30:17","slug":"dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","title":{"rendered":"\u00c8 disponibile il sistema di gestione dei codici sorgente Git 2.41","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo tre mesi di sviluppo, \u00e8 stata pubblicata la versione 2.41 del sistema di gestione distribuita dei codici sorgente Git. Git \u00e8 uno dei sistemi di gestione delle versioni pi\u00f9 popolari, affidabili e ad alte prestazioni, che offre strumenti flessibili per lo sviluppo non lineare basati su ramificazioni e fusioni. Per garantire l'integrit\u00e0 della cronologia e la resilienza alle modifiche \"retroattive\", viene utilizzata l'hashing implicito di tutta la cronologia precedente in ogni commit; \u00e8 inoltre possibile la certificazione tramite le firme digitali degli sviluppatori di singoli tag e commit. <\/p>\n
Rispetto alla versione precedente, sono stati introdotti 542 cambiamenti nella nuova versione, realizzati con la partecipazione di 95 sviluppatori, di cui 29 hanno partecipato per la prima volta allo sviluppo. Le principali novit\u00e0 includono: <\/p>\n
\n
\u00c8 stato migliorato il trattamento degli oggetti inaccessibili, per i quali non ci sono riferimenti nel repository (cio\u00e8 branch o tag non puntano). Gli oggetti inaccessibili vengono eliminati dal collector di spazzatura, ma rimangono nel repository per un certo tempo prima della rimozione, per escludere stati di race. Per monitorare il periodo di presenza degli oggetti inaccessibili, \u00e8 necessario collegarvi etichette con il tempo di modifica di tali oggetti, il che non consente di conservarli in un unico file pack, in cui tutti gli oggetti hanno un tempo di modifica comune. In precedenza, ogni oggetto inaccessibile veniva salvato in un file separato, causando problemi con un gran numero di nuovi oggetti inaccessibili che non erano ancora soggetti a eliminazione. Nella nuova versione, per il confezionamento degli oggetti inaccessibili, viene utilizzato per impostazione predefinita il meccanismo \"cruft packs\", che consente di memorizzare tutti gli oggetti inaccessibili in un unico file pack, mentre i dati sul tempo di modifica di ciascun oggetto vengono riportati in una tabella separata, memorizzata in un file con estensione \".mtimes\" e collegata tramite un file indice con estensione \".idx\".
<\/center>\n
\u00c8 abilitata per impostazione predefinita la registrazione su disco dell'indice inverso (revindex) per i file pack. Durante il test nel repository torvalds\/linux, l'uso dell'indice inverso ha consentito di accelerare le operazioni intensive di risorse \"git push\" di 1,49 volte, e le operazioni semplici, come il calcolo della dimensione di un singolo oggetto tramite \"git cat-file --batch='%(objectsize:disk)'\" di 77 volte. I file (\".rev\") con l'indice inverso saranno salvati all'interno del repository nella cartella \".git\/objects\/pack\".\n
Ricordiamo che Git memorizza tutti i dati sotto forma di oggetti, che sono collocati in singoli file. Per migliorare l'efficienza nel lavoro con il repository, gli oggetti vengono ulteriormente inseriti in file pack, nei quali le informazioni sono presentate come un flusso di oggetti che seguono uno dopo l'altro (un formato analogo \u00e8 utilizzato quando si trasferiscono oggetti con i comandi git fetch e git push). Per ogni file pack viene creato un file di indice (.idx), che consente di determinare molto rapidamente l'offset nel file pack in cui \u00e8 memorizzato l'oggetto corrispondente mediante l'ID dell'oggetto. <\/p>\n
L'indice inverso incluso nella nuova versione mira a ottimizzare il processo di identificazione dell'oggetto in base alle informazioni di posizionamento dell'oggetto nel file pack. In precedenza, tale trasformazione avveniva in tempo reale durante l'analisi del file pack e veniva conservata solo in memoria, il che non permetteva di riutilizzare tali indici e costringeva a generare un indice ogni volta. L'operazione di costruzione dell'indice consiste nella creazione di un array di coppie \u00aboggetto-posizione\u00bb e nella sua ordinazione per posizione, il che pu\u00f2 richiedere molto tempo per file pack di grandi dimensioni. <\/p>\n
Ad esempio, l'operazione di visualizzazione del contenuto degli oggetti, in cui si utilizza l'indice diretto, veniva eseguita 62 volte pi\u00f9 velocemente rispetto all'operazione di visualizzazione della dimensione degli oggetti, per la quale i dati sul collegamento della posizione con l'oggetto non erano indicizzati. Dopo l'uso dell'indice inverso, le operazioni indicate hanno iniziato a richiedere all'incirca lo stesso tempo. Gli indici inversi consentono anche di accelerare le operazioni di invio degli oggetti durante l'esecuzione dei comandi fetch e push grazie alla trasmissione diretta dei dati gi\u00e0 pronti dal disco.
<\/center> <\/p>\n
Nel protocollo \u00abcredential helper\u00bb, utilizzato per la trasmissione delle credenziali durante l'accesso ai repository a accesso limitato, \u00e8 stata aggiunta la supporto per la trasmissione delle intestazioni WWW-Authenticate tra il gestore delle credenziali e il servizio in cui avviene l'autenticazione. Il supporto per l'intestazione WWW-Authenticate consente di trasmettere parametri scope OAuth per una divisione pi\u00f9 granulare dell'accesso dell'utente ai repository e per delimitare le aree disponibili per le richieste.\n
\u00c8 stata aggiunta all comando for-each-ref l'opzione di formattazione \u00ab%(ahead-behind:<base>)\u00bb, che permette di ottenere informazioni sul numero di commit presenti o assenti in un dato ramo rispetto a un altro ramo (quanto un ramo \u00e8 in ritardo o in anticipo rispetto a un altro a livello di commit). In precedenza, per ottenere tali informazioni era necessario eseguire due comandi separati: \u00abgit rev-list \u2014count main..my-feature\u00bb per ottenere il numero di commit unici al ramo e \u00abgit rev-list \u2014count my-feature..main\u00bb per ottenere il numero di commit assenti. Ora tali calcoli possono essere ridotti a un solo comando, semplificando la scrittura dei gestori e riducendo il tempo di esecuzione. Ad esempio, per mostrare i rami non uniti e valutare il ritardo o l'anticipo rispetto al loro ramo principale, si pu\u00f2 utilizzare una riga di comando: $ git for-each-ref \u2014no-merged=origin\/HEAD \ \u2014format='%(refname:short) %(ahead-behind:origin\/HEAD)' \ refs\/heads\/tb\/ | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref\u2014exclude 16 96 tb\/roaring-bitmaps 47 3 invece dello script precedentemente utilizzato, che veniva eseguito 17 volte pi\u00f9 lentamente: $ git for-each-ref \u2014format='%(refname:short)' \u2014no-merged=origin\/HEAD \ refs\/heads\/tb | while read ref do ahead='$(git rev-list \u2014count origin\/HEAD..$ref)' behind='$(git rev-list \u2014count $ref..origin\/HEAD)' printf \u00ab%s %d %d\n\u00bb \u00ab$ref\u00bb \u00ab$ahead\u00bb \u00ab$behind\u00bb done | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref\u2014exclude 16 96 tb\/roaring-bitmaps 47 3\n
\u00c8 stata aggiunta all comando \u00abgit fetch\u00bb l'opzione \u00ab\u2014porcelain\u00bb, che, se specificata, genera un output nel formato \u00ab \u00bb, meno leggibile, ma pi\u00f9 comodo per l'analisi negli script.\n
![\"\u00c8](\"\/wp-content\/uploads\/2023\/06\/1158b26b1dfd1c16c93017669224d7a4.png\")
<\/center>\n![\"\u00c8](\"\/wp-content\/uploads\/2023\/06\/ed6cb7102da37d1262fd3079ac983158.png\")
<\/center> <\/p>\n