{"id":118622,"date":"2024-07-30T09:43:00","date_gmt":"2024-07-30T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46"},"modified":"2024-07-30T09:43:00","modified_gmt":"2024-07-30T07:43:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","title":{"rendered":"Rilascio del sistema di controllo delle versioni Git 2.46","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo tre mesi di sviluppo, \u00e8 stata pubblicata la versione 2.46 del sistema distribuito di gestione dei sorgenti Git. Git \u00e8 uno dei sistemi di gestione delle versioni pi\u00f9 popolari, affidabili e performanti, che offre strumenti flessibili per lo sviluppo non lineare basati su ramificazioni e fusioni. Per garantire l'integrit\u00e0 della cronologia e la resistenza ai cambiamenti retroattivi, viene utilizzata l'hashing implicito dell'intera cronologia precedente in ogni commit; \u00e8 anche possibile la verifica tramite firme digitali degli sviluppatori su singoli tag e commit. Il codice di Git \u00e8 distribuito con licenza GPLv2+. <\/p>\n
Rispetto alla versione precedente, nella nuova versione sono stati introdotti 746 cambiamenti, preparati con la partecipazione di 96 sviluppatori, di cui 31 partecipano per la prima volta allo sviluppo. Le principali novit\u00e0: <\/p>\n
\n
Aggiunta il supporto sperimentale per un nuovo tipo di bitmap \u2014 la 'pseudo-merge reachability bitmap', nella quale, a differenza della struttura 'reachability bitmap', i dati sui set di oggetti relativi ai commit non sono memorizzati legati a ciascun singolo commit, ma legati a pi\u00f9 commit contemporaneamente. Questa organizzazione consente di utilizzare una singola bitmap per determinare gli oggetti per commit in rami diversi, il che in repository di grandi dimensioni permette di evitare la creazione di un numero elevato di bitmap separate e accelera notevolmente l'analisi degli oggetti per determinare quali oggetti inviare al client durante operazioni come 'git fetch', 'git rev-list' e 'git clone'. Per abilitare il nuovo tipo di bitmap e definire la logica della loro selezione e utilizzo, \u00e8 stata proposta una serie di configurazioni 'bitmapPseudoMerge': git config bitmapPseudoMerge.all.pattern 'refs\/(heads|tags)\/' git config bitmapPseudoMerge.all.threshold now git config bitmapPseudoMerge.all.stableThreshold never git repack -adb\n
\u00c8 stato implementato un nuovo interface della riga di comando per il comando 'git config', nel quale invece delle opzioni disperse per visualizzare, rinominare ed eliminare impostazioni e sezioni, come '--get', '--get-all', '--unset' e '--remove-section', \u00e8 stato proposto un insieme di sottocomandi separati. Ad esempio, per visualizzare tutte le impostazioni del repository ora \u00e8 possibile utilizzare il comando 'git config list', e per visualizzare il contenuto di un determinato parametro \u2014 il comando 'git config get '. Per filtrare ulteriormente i risultati, utilizzando l'opzione '--regexp' \u00e8 possibile impostare un filtro basato su una espressione regolare.\n
Nel protocollo «credential helper», utilizzato per trasmettere le credenziali quando si accede a repository con accesso limitato, \u00e8 stata aggiunta la supporto per i nuovi campi «authtype» e «credential», che consentono di creare gestori per i sistemi di autenticazione HTTP che non si limitano alla verifica di nome utente e password, ad esempio nell'uso del Bearer Token in OAuth 2.0. Prima di ci\u00f2, per lavorare con tali sistemi di autenticazione, era necessario specificare i dati sensibili in chiaro nel parametro http.extraHeader. Inoltre, nel protocollo \u00e8 stata aggiunta la possibilit\u00e0 di salvare lo stato di ciascun gestore delle credenziali per supportare metodi di autenticazione a pi\u00f9 fasi, utilizzati in protocolli come NTLM e Kerberos.\n
\u00c8 continuato lo sviluppo del backend sperimentale «reftable» per l'archiviazione efficiente nel repository di riferimenti a branch e tag. Questo backend utilizza uno storage a blocchi, impiegato dal progetto JGit e ottimizzato per memorizzare un numero molto elevato di riferimenti (i tradizionali formati di archiviazione dei riferimenti comportano costi significativi nei repository con un gran numero di riferimenti a causa della creazione di un numero molto elevato di file in una sola directory nel caso di archiviazione dei riferimenti nella directory $GIT_DIR\/refs o della necessit\u00e0 di sovrascrivere un grande file ad ogni aggiornamento nel caso di archiviazione dei riferimenti nel file $GIT_DIR\/packed_refs). Nella nuova versione \u00e8 stato aggiunto il comando «git refs migrate —ref-format=reftable» per migrare repository esistenti al backend «reftable» (in precedenza, il backend veniva attivato solo durante l'inizializzazione del repository).\n
Nel comando git \u00e8 stata aggiunta l'opzione «—no-advice», che disabilita tutti i messaggi di raccomandazione e suggerimenti, il che pu\u00f2 rivelarsi utile per evitare il sovraccarico del log con informazioni superflue durante la chiamata automatizzata di git.\n
\u00c8 iniziato il processo di conversione di alcuni controlli del set di test all'uso dei test unitari, semplificando il test dei componenti a basso livello e migliorando l'efficienza del processo di testing sulla piattaforma Windows, dove si riscontrano costi elevati nell'avviare un grande numero di processi durante l'esecuzione di test implementati come script shell.\n
Nel codice per l'analisi delle impostazioni dei colori \u00e8 stata aggiunta la possibilit\u00e0 di utilizzare la rappresentazione «#RGB» in aggiunta a «#RRGGBB». <\/ul>\n