{"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\/novosti-interneta\/dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","title":{"rendered":"\u00c8 disponibile il sistema di gestione dei testi 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 distribuito di controllo delle versioni Git. Git \u00e8 uno dei sistemi di gestione delle versioni pi\u00f9 popolari, affidabili e ad alte prestazioni, che offre strumenti flessibili per uno sviluppo non lineare, basato su ramificazioni e fusioni di rami. Per garantire l'integrit\u00e0 della storia e la resilienza alle modifiche 'retroattive', viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, ed \u00e8 anche possibile la verifica tramite firme digitali dei singoli tag e commit da parte degli sviluppatori. <\/p>\n
Rispetto alla versione precedente, nella nuova versione sono stati inclusi 542 cambiamenti, frutto della collaborazione di 95 sviluppatori, 29 dei quali hanno partecipato per la prima volta allo sviluppo. Le principali novit\u00e0: <\/p>\n
\n
Migliorata la gestione degli oggetti irraggiungibili (unreachable) per i quali non ci sono riferimenti nel repository (non referenziati da rami o tag). Gli oggetti irraggiungibili vengono rimossi dal raccoglitore di spazzatura, ma rimangono nel repository per un certo periodo di tempo prima della rimozione, per escludere stati di competizione. Per tracciare il periodo di permanenza degli oggetti irraggiungibili \u00e8 necessaria l'associazione di etichette con il timestamp di modifica di tali oggetti, il che impedisce di conservarli in un unico file pack, in cui tutti gli oggetti hanno un tempo di modifica comune. In precedenza, ogni oggetto irraggiungibile veniva salvato in un file separato, il che causava problemi quando c'erano molti oggetti irraggiungibili freschi, che non erano ancora soggetti a rimozione. Nella nuova versione, per l'imballaggio degli oggetti irraggiungibili viene utilizzato per impostazione predefinita il meccanismo \u00abcruft packs\u00bb, che consente di salvare tutti gli oggetti irraggiungibili in un unico file pack, mentre i dati sul tempo di modifica di ciascun oggetto vengono riflessi in una tabella separata, conservata in un file con estensione \u00ab.mtimes\u00bb e collegata tramite un file indice con estensione \u00ab.idx\u00bb.
<\/center>\n
Per impostazione predefinita, la gestione del disco dell'indice inverso (revindex) \u00e8 abilitata per i file pack. Durante i test sul repository torvalds\/linux, l'uso dell'indice inverso ha permesso di accelerare le operazioni ad alta intensit\u00e0 di risorse come 'git push' di 1,49 volte, mentre le operazioni semplici, come il calcolo della dimensione di un singolo oggetto utilizzando 'git cat-file --batch='%(objectsize:disk)'' sono state accelerate di 77 volte. I file ('.rev') con indice inverso saranno archiviati 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 file separati. Per migliorare l'efficienza del lavoro con il repository, gli oggetti vengono ulteriormente collocati in file pack, nei quali le informazioni sono presentate sotto forma di flusso di oggetti che si susseguono (un formato simile \u00e8 utilizzato durante il trasferimento di oggetti con i comandi git fetch e git push). Per ogni file pack viene creato un file indice (.idx), che consente di determinare molto rapidamente l'offset nel file pack in base all'identificatore dell'oggetto per cui \u00e8 memorizzato quest'oggetto. <\/p>\n
L'indice inverso incluso nella nuova versione \u00e8 destinato a ottimizzare il processo di identificazione di un oggetto in base alle informazioni di posizionamento nell'archivio pack. In precedenza, questa conversione veniva eseguita al volo durante l'analisi dell'archivio pack e memorizzata solo in memoria, il che non consentiva di riutilizzare tali indici e obbligava a generare l'indice ogni volta. L'operazione di costruzione dell'indice si limita a costruire un array di coppie \"oggetto-posizione\" e a ordinarlo per posizione, il che pu\u00f2 richiedere molto tempo per grandi archivi pack. <\/p>\n
Ad esempio, l'operazione di visualizzazione del contenuto degli oggetti, in cui viene utilizzato un indice diretto, \u00e8 stata eseguita 62 volte pi\u00f9 velocemente rispetto all'operazione di visualizzazione delle dimensioni degli oggetti, per la quale i dati di collegamento tra posizione e oggetto non erano indicizzati. Dopo l'uso dell'indice inverso, le operazioni indicate hanno cominciato 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 «credential helper», utilizzato per la trasmissione delle credenziali durante l'accesso ai repository con accesso limitato, \u00e8 stata aggiunta la supporto per la trasmissione degli header WWW-Authenticate tra il gestore delle credenziali e il servizio in cui avviene l'autenticazione. Il supporto per l'header WWW-Authenticate consente di trasmettere i parametri scope di OAuth per un'accesso pi\u00f9 granulare ai repository e per delineare le aree accessibili alle richieste.\n
Nel comando for-each-ref \u00e8 stata aggiunta l'opzione di formattazione «%(ahead-behind:<base>)», che consente di ottenere informazioni sul numero di commit presenti o assenti in un certo 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: «git rev-list —count main..my-feature» per ottenere il numero di commit unici per il ramo e «git rev-list —count my-feature..main» per ottenere il numero di commit assenti. Ora tali calcoli possono essere ridotti a un solo comando, semplificando la scrittura degli handler e riducendo i tempi di esecuzione. Ad esempio, per mostrare i rami non uniti e valutare il ritardo o il vantaggio rispetto al ramo principale, si pu\u00f2 utilizzare una riga di comando: $ git for-each-ref —no-merged=origin\/HEAD \ —format=’%(refname:short) %(ahead-behind:origin\/HEAD)’ \ refs\/heads\/tb\/ | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref—exclude 16 96 tb\/roaring-bitmaps 47 3 invece del precedente script, che veniva eseguito 17 volte pi\u00f9 lentamente: $ git for-each-ref —format=’%(refname:short)’ —no-merged=origin\/HEAD \ refs\/heads\/tb | while read ref do ahead=»$(git rev-list —count origin\/HEAD..$ref)» behind=»$(git rev-list —count $ref..origin\/HEAD)» printf «%s %d %d\n» «$ref» «$ahead» «$behind» done | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref—exclude 16 96 tb\/roaring-bitmaps 47 3\n
Nel comando «git fetch» \u00e8 stata aggiunta l'opzione «—porcelain», che produce un output nel formato «<flag> <old-object-id> <new-object-id> <local-reference>», meno leggibile ma pi\u00f9 utile 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