Rilascio del sistema di controllo del codice sorgente distribuito Git 2.26

A disposizione rilascio di un sistema di controllo del codice sorgente distribuito Git 2.26.0. Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che fornisce strumenti di sviluppo flessibili e non lineari basati su branching e merging. Per garantire l’integrità della storia e la resistenza a modifiche retroattive, in ogni commit viene utilizzato l’hashing implicito di tutta la storia precedente; è inoltre possibile certificare i singoli tag e commit con firme digitali degli sviluppatori.

Rispetto alla versione precedente, la nuova versione comprende 504 modifiche, preparate con la partecipazione di 64 sviluppatori, di cui 12 hanno preso parte allo sviluppo per la prima volta. Il principale innovazioni:

  • È stato impostato il valore predefinito seconda versione Protocollo di comunicazione Git, utilizzato quando un client si connette in remoto a un server Git. La seconda versione del protocollo si distingue per fornire la possibilità di filtrare rami e tag sul lato server, restituendo un elenco abbreviato di collegamenti al client. In precedenza, qualsiasi comando pull inviava sempre al client l'elenco completo dei riferimenti nell'intero repository, anche quando il client stava aggiornando solo un ramo o verificando che la propria copia del repository fosse aggiornata. Un'altra innovazione degna di nota è la possibilità di aggiungere nuove funzionalità al protocollo non appena nuove funzionalità diventano disponibili nel toolkit. Il codice client rimane compatibile con il vecchio protocollo e può continuare a funzionare sia con i nuovi che con i vecchi server, tornando automaticamente alla prima versione se il server non supporta la seconda.
  • L'opzione “-show-scope” è stata aggiunta al comando “git config”, rendendo più semplice identificare il luogo in cui sono definite determinate impostazioni. Git ti consente di definire le impostazioni in diversi posti: nel repository (.git/info/config), nella directory dell'utente (~/.gitconfig), nel file di configurazione a livello di sistema (/etc/gitconfig) e tramite il comando opzioni di linea e variabili di ambiente. Quando si esegue “git config” è abbastanza difficile capire dove è definita esattamente l'impostazione desiderata. Per risolvere questo problema era disponibile l'opzione “--show-origin”, che però mostra solo il percorso del file in cui è definita l'impostazione, utile se si intende modificare il file, ma non aiuta se si è necessario modificare il valore tramite "git config" utilizzando le opzioni "--system", "--global" o "-local". La nuova opzione "--show-scope" mostra il contesto della definizione della variabile e può essere utilizzata insieme a -show-origin:

    $ git --list --show-scope --show-origin
    file globale:/home/user/.gitconfig diff.interhunkcontext=1
    file globale:/home/utente/.gitconfig push.default=current
    […] file locale:.git/config branch.master.remote=origin
    file locale:.git/config branch.master.merge=refs/heads/master

    $ git config --show-scope --get-regexp 'diff.*'
    larghezza differenziale globale statgraph 35
    locale diff.colormoved pianura

    $ git config --global --unset diff.statgraphwidth

  • Nelle impostazioni di rilegatura credenziali È consentito l'uso di maschere negli URL. Qualsiasi impostazione e credenziale HTTP in Git può essere impostata sia per tutte le connessioni (http.extraHeader, credential.helper) sia per le connessioni basate su URL (credential.https://example.com.helper, credential.https: //example. com.helper). Fino ad ora, i caratteri jolly come *.example.com erano consentiti solo per le impostazioni HTTP, ma non erano supportati per l'associazione delle credenziali. In Git 2.26 queste differenze vengono eliminate e, ad esempio, per associare un nome utente a tutti i sottodomini è ora possibile specificare:

    [credenziale "https://*.esempio.com"]

    nome utente = ttaylorr

  • Continua l'espansione del supporto sperimentale per la clonazione parziale (cloni parziali), che consente di trasferire solo parte dei dati e lavorare con una copia incompleta del repository. La nuova versione aggiunge un nuovo comando "git sparse-checkout add", che consente di aggiungere singole directory per applicare l'operazione di "checkout" solo a una parte dell'albero di lavoro, invece di elencare tutte queste directory contemporaneamente tramite il comando "git sparse-checkout set" (è possibile aggiungere una directory alla volta, senza specificare nuovamente l'intero elenco ogni volta).
    Ad esempio, per clonare un repository git/git senza eseguire il commit dei blob, limitando il checkout solo alla directory root della copia di lavoro e contrassegnando separatamente il checkout per le directory "t" e "Documentation", potresti specificare:

    $ git clone --filter=blob:none --sparse [email protected]:git/git.git

    $ cd git
    $ git sparse-checkout init --cone

    $ git sparse-checkout aggiungi t
    ....
    $ git sparse-checkout aggiungi documentazione
    ....
    $ git lista di pagamento sparsa
    Documentazione
    t

  • Le prestazioni del comando “git grep”, utilizzato per ricercare sia i contenuti attuali del repository che le revisioni storiche, sono state notevolmente migliorate. Per velocizzare la ricerca era possibile scansionare il contenuto dell'albero di lavoro utilizzando più thread (“git grep –threads”), ma la ricerca nelle revisioni storiche era a thread singolo. Ora questa limitazione è stata rimossa implementando la possibilità di parallelizzare le operazioni di lettura dallo storage degli oggetti. Per impostazione predefinita, il numero di thread è impostato uguale al numero di core della CPU, che nella maggior parte dei casi ora non richiede l'impostazione esplicita dell'opzione "-threads".
  • Aggiunto il supporto per il completamento automatico dell'input di sottocomandi, percorsi, collegamenti e altri argomenti del comando "git worktree", che consente di lavorare con diverse copie funzionanti del repository.
  • Aggiunto supporto per colori brillanti con sequenze di escape ANSI. Ad esempio, nelle impostazioni per i colori evidenziati “git config –color” o “git diff –color-moved” è possibile specificare “%C(brightblue)” tramite l’opzione “--format” per il blu brillante.
  • Aggiunta nuova versione dello script fsmonitor-guardiano, garantendo l'integrazione con il meccanismo Guardiano di Facebook per accelerare il monitoraggio delle modifiche ai file e la comparsa di nuovi file. Dopo l'aggiornamento è richiesto git sostituire agganciare nel repository.
  • Aggiunte ottimizzazioni per velocizzare i cloni parziali quando si utilizzano bitmap
    (macchine bitmap) per evitare una ricerca completa di tutti gli oggetti durante il filtraggio dell'output. Ora viene eseguito il controllo dei BLOB (—filter=blob:none e —filter=blob:limit=n) durante la clonazione parziale
    significativamente più veloce. GitHub ha annunciato patch con queste ottimizzazioni e supporto sperimentale per la clonazione parziale.

  • Il comando "git rebase" è stato spostato su un backend diverso, utilizzando il meccanismo predefinito 'merge' (precedentemente utilizzato per "rebase -i") invece di 'patch+apply'. I backend differiscono in alcuni piccoli aspetti, ad esempio, dopo aver continuato un'operazione dopo aver risolto un conflitto (git rebase --continue), il nuovo backend offre di modificare il messaggio di commit, mentre quello vecchio utilizzava semplicemente il vecchio messaggio. Per ripristinare il vecchio comportamento, puoi utilizzare l'opzione "--apply" o impostare la variabile di configurazione "rebase.backend" su "apply".
  • Un esempio di gestore per i parametri di autenticazione specificati tramite .netrc è stato ridotto a una forma adatta all'uso immediato.
  • Aggiunta l'impostazione gpg.minTrustLevel per impostare il livello minimo di attendibilità per vari elementi che eseguono la verifica della firma digitale.
  • Aggiunta l'opzione "--pathspec-from-file" a "git rm" e "git stash".
  • È continuato il miglioramento delle suite di test in preparazione al passaggio all'algoritmo di hashing SHA-2 anziché SHA-1.

Fonte: opennet.ru

Aggiungi un commento