Uscita del sistema di gestione distribuita dei sorgenti Git 2.25

Disponibile rilascio del sistema di controllo distribuito delle versioni Git 2.25.0. Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che offre strumenti flessibili per lo sviluppo non lineare, basati su ramificazioni e fusioni. Per garantire l'integrità della cronologia e resistere a modifiche retroattive, viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, oltre alla possibilità di autentificazione con firme digitali da parte degli sviluppatori per singoli tag e commit.

Rispetto all'uscita precedente, nella nuova versione sono stati accolti 583 cambiamenti, elaborati con la partecipazione di 84 sviluppatori, di cui 32 hanno partecipato per la prima volta allo sviluppo. Principali novità:

  • Si sta avvicinando alla stabilizzazione e alla piena prontezza la funzione di clonazione parziale (partial clones), che consente di trasferire solo una parte dei dati e lavorare con una copia incompleta del repository. Durante la clonazione normale, vengono copiati tutti i dati, comprese tutte le versioni di ciascun file nella cronologia delle modifiche. Per repository molto grandi, la copia dei dati porta a un significativo incremento del traffico e dello spazio su disco, anche se l'interesse del sviluppatore è solo per un sottoinsieme di file. Per semplificare l'ottenimento di solo una parte dell'albero di lavoro dei sorgenti, in questa nuova versione è stata proposta un comando sperimentale «sparse-checkout» e una nuova opzione «—sparse» per il comando «clone».

    In precedenza, il processo di clonazione selettiva veniva effettuato impostando filtri per filtrare contenuti non necessari e l'opzione «—no-checkout» per disabilitare il ripristino dei file mancanti. Dopo di che, prima di eseguire l'operazione di checkout, era necessario abilitare l'impostazione core.sparseCheckout e definire nel file .git/info/sparse-checkout un elenco di modelli di percorsi esclusi. Ad esempio, per clonare senza blob e impedire l'estrazione di file da sottocartelle di profondità 2 o oltre, si poteva eseguire:

    git clone —filter=blob:none —no-checkout /your/repository/here repo
    $ cd repo
    $ cat >.git/info/sparse-checkout <EOF
    /*
    !/*
    EOF
    $ git config core.sparseCheckout 1
    $ git checkout .

    Il nuovo comando «git sparse-checkout» semplifica notevolmente il lavoro e riduce il processo di organizzazione del lavoro con un repository incompleto ai comandi:

    git clone —filter=blob:none —sparse /your/repository/here repo
    git sparse-checkout set /path/to/check/out

    Il comando sparse-checkout consente di impostare un elenco di percorsi per checkout (set) senza la necessità di configurare manualmente .git/info/sparse-checkout, e permette anche di visualizzare l'elenco corrente di percorsi (list) e abilitare o disabilitare il checkout parziale (enable/disable).

    Per ottimizzare il lavoro con repository molto grandi e l'elenco di modelli, è stata proposta un'impostazione «git config core.sparseCheckoutCone», che limita i modelli consentiti (invece di modelli arbitrari di .gitignore, si può specificare quali percorsi e quali file in un sottocartella specificata dovrebbero essere estratti). Ad esempio, se in un grande repository esiste una cartella «A/B/C» e tutto il lavoro è concentrato nella sottocartella «C», attivando la modalità sparseCheckoutCone, il comando «git sparse-checkout set A/B/C» estrarrà completamente il contenuto di «C», ma da «A» e «B» estrarrà solo le parti necessarie per lavorare con «C».

  • Dalla documentazione («git rebase -h») sono state rimosse tutte le menzioni all'opzione «—preserve-merges», che è stata dichiarata obsoleta e al suo posto per trasferire un insieme di commit si dovrebbe usare «git rebase —rebase-merges«.
  • Per migliorare la leggibilità dei messaggi con patch inviati a mailing list, è stata aggiunta l'opzione «git format-patch —cover-from-description subject», che, se specificata, utilizza il primo paragrafo del testo della descrizione del ramo come oggetto della mail di accompagnamento per il set di patch.
  • È stata implementata la compatibilità tra il comando «git apply —3way» e l'impostazione «merge.conflictStyle» («git apply» ora considera lo stile di descrizione del conflitto da merge.conflictStyle in caso di necessità di risolvere un conflitto dopo un tentativo di applicare un file patch al repository).
  • Il codice per la definizione delle funzioni, utilizzato in operazioni come «git diff/grep —show-function/—function-context», è stato ampliato con il supporto per la definizione dei confini delle funzioni nei programmi in Elixir.
  • Nelle comandi «git add», «git commit», «git reset» e altri, è stata aggiunta una nuova opzione «—pathspec-from-file», che consente di caricare un elenco di percorsi da un file o da uno stream di input, invece di elencarli nella riga di comando.
  • È stato risolto un problema con la definizione delle rinominazioni a livello di directory durante la registrazione dei commit. La definizione non funzionava nel caso di spostamento del contenuto di una sottocartella nella radice del repository.
  • È stata proposta un'implementazione iniziale del comando riprogettato «git add -i», che consente di aggiungere contenuti modificati in modalità interattiva, riscritto da Perl a C. È in corso una riprogettazione analoga del comando «git add -p».
  • È stata effettuata una rifattorizzazione del comando «git log —graph», che genera un'immagine ASCII del grafo con la cronologia delle modifiche nel repository. Questa riprogettazione ha permesso di migliorare e semplificare notevolmente l'output senza distorcere la struttura della storia, il che ha risolto, ad esempio, il problema con l'uscita dell'immagine oltre il limite della larghezza della riga del terminale.
  • L'opzione «git log —format=..», che consente di modificare il formato di output,
    è stata ampliata con il supporto per i flag «l/L» per visualizzare solo una parte dell'indirizzo email, indicata prima del simbolo «@» (ad esempio, utile quando tutti gli sviluppatori hanno tutti gli email nello stesso dominio).
  • Nella comando «git submodule» è stata aggiunta la sottocomando «set-url».
  • I set di test sono stati aggiornati in preparazione al passaggio a
    l'algoritmo di hashing SHA-2 invece di SHA-1.

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster