lancement d'un système de gestion décentralisé des textes sources . Git est l'un des systèmes de gestion de versions les plus populaires, fiables et performants, offrant des outils flexibles de développement non linéaire basés sur le branchement et la fusion. Pour garantir l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de l'ensemble de l'historique précédent est utilisé dans chaque commit, et il est également possible de vérifer numériquement par des signatures des développeurs pour des tags et commits spécifiques.
Comparé à la version précédente, cette nouvelle version intègre 583 modifications, élaborées avec la participation de 84 développeurs, dont 32 ont participé au développement pour la première fois. :
- La possibilité de clonage partiel (partial clones) approche d'une stabilisation et d'une pleine disponibilité, permettant de transférer seulement une partie des données et de travailler avec une copie incomplète du dépôt. Lors d'un clonage traditionnel, toutes les données, y compris chaque version de chaque fichier de l'historique des modifications, sont copiées. Pour des dépôts très volumineux, la copie des données entraîne une augmentation significative du trafic et de l'espace disque, même si le développeur n'est intéressé que par un sous-ensemble de fichiers. Pour simplifier l'obtention d'une partie de l'arborescence des sources, cette nouvelle version propose une commande expérimentale « sparse-checkout » et une nouvelle option « —sparse » pour la commande « clone ».
Auparavant, le processus de clonage sélectif était effectué en définissant pour filtrer le contenu indésirable et l'option « —no-checkout » pour désactiver la récupération des fichiers manquants. Ensuite, avant d'exécuter l'opération de checkout, il était nécessaire d'activer le paramètre core.sparseCheckout et de définir dans le fichier .git/info/sparse-checkout une liste de modèles de chemins à exclure. Par exemple, pour cloner sans blobs et interdire l'extraction de fichiers dans des répertoires imbriqués d'une profondeur de 2 et plus, il était possible d'exécuter :
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 .La nouvelle commande « git sparse-checkout » simplifie considérablement le travail et réduit le processus de gestion d'un dépôt incomplet à des commandes :
git clone —filter=blob:none —sparse /your/repository/here repo
git sparse-checkout set /path/to/check/outLa commande sparse-checkout permet de définir une liste de chemins pour le checkout (set) sans avoir à configurer manuellement .git/info/sparse-checkout, ainsi que d'afficher la liste actuelle des chemins (list) et d'activer ou de désactiver les checkouts partiels (enable/disable).
Pour optimiser le travail avec des dépôts très volumineux et des listes de modèles, une configuration appelée ««, limitant les modèles autorisés (au lieu de modèles .gitignore arbitraires, on peut spécifier quels chemins et fichiers dans un sous-répertoire donné doivent être extraits). Par exemple, si dans un grand dépôt il y a un répertoire «A/B/C» et que tout le travail est concentré dans le sous-répertoire «C», alors en activant le mode sparseCheckoutCone, la commande «git sparse-checkout set A/B/C» extraira complètement le contenu de «C», mais n'extraira de «A» et «B» que les parties nécessaires au travail sur «C».
- Tous les passages sur l'option «—preserve-merges», déclarée obsolète, ont été supprimés de la documentation («git rebase -h»), et à la place pour le transfert d'un ensemble de commits, il convient d'utiliser ««.
- Pour améliorer la lisibilité des messages de patch envoyés sur des listes de diffusion, une nouvelle option «git format-patch —cover-from-description subject» a été ajoutée, qui, lorsqu'elle est spécifiée, utilise le premier paragraphe du texte de la description de la branche comme sujet du courrier d'accompagnement pour l'ensemble de patch.
- La prise en charge de l'utilisation conjointe de la commande «git apply —3way» et du paramètre «merge.conflictStyle» a été mise en œuvre («git apply» prend désormais en compte le style de description de conflit de merge.conflictStyle lorsque cela est nécessaire pour résoudre un conflit après avoir tenté d'appliquer un fichier patch au dépôt).
- Le code de définition des fonctions, utilisé dans des opérations telles que «git diff/grep —show-function/—function-context», a été étendu avec la prise en charge de la définition des limites des fonctions dans les programmes en .
- Une nouvelle option «—pathspec-from-file» a été ajoutée aux commandes «git add», «git commit», «git reset» et autres, permettant de charger une liste de chemins depuis un fichier ou un flux d'entrée, au lieu de les énumérer sur la ligne de commande.
- Un problème de détermination des renommages au niveau des répertoires lors de l'enregistrement des commits a été résolu. La détermination ne fonctionnait pas lors du déplacement du contenu d'un sous-répertoire vers la racine du dépôt.
- Une première mise en œuvre de la commande remaniée «git add -i» a été proposée, permettant d'ajouter le contenu modifié en mode interactif, réécrite de Perl en C. Une refonte similaire de la commande «git add -p» est en cours.
- La commande «git log —graph», qui génère une image ASCII du graphe des modifications dans le dépôt, a été refactorisée. Cette refonte a permis d'améliorer significativement et de simplifier la sortie sans déformer la structure de l'historique, ce qui a par exemple résolu le problème des images dépassant la largeur de la ligne du terminal.
- L'option « git log --format=.. » permettant de modifier le format de sortie,
a été étendue avec le support des indicateurs « l/L » pour n'afficher qu'une partie de l'adresse e-mail, spécifiée avant le symbole « @ » (par exemple, utile lorsque tous les développeurs ont des emails dans un même domaine). - La commande « git submodule » a ajouté la sous-commande « set-url ».
- Les ensembles de tests ont été mis à jour dans le cadre de la préparation au passage à
l'algorithme de hachage SHA-2 au lieu de SHA-1.
Source : opennet.ru
