Avec Git 2.18, vous avez plus de contrôle sur la façon dont vous souhaitez spécifier les couleurs dans la console.
La git configcommande " " utilise des options distinctes, par exemple " --int", " --bool", etc. pour spécifier le type auquel l'appelant veut que la valeur soit interprétée comme .
Une nouvelle --type=<typename>option " " a été introduite, ce qui rendrait plus propre la définition de nouveaux types.
Voir commit fb0dc3b (18 avril 2018) et commit 0a8950b (09 avril 2018) par Taylor Blau ( ttaylorr) .
(Fusionné par Junio C Hamano - gitster- en commit e3e042b , 08 mai 2018)
builtin/config.c: support --type=<type>comme alias préféré pour--<type>
git config a longtemps permis aux appelants de fournir un «spécificateur de type», qui indique git config (1) de s'assurer que les valeurs entrantes peuvent être interprétées comme ce type, et (2) que les valeurs sortantes sont canonisées sous ce type.
Dans une autre série, nous proposons d'étendre cette fonctionnalité avec
--type=coloret --defaultde la remplacer --get-color.
Cependant, nous utilisons traditionnellement --colorpour signifier "coloriser cette sortie", au lieu de "cette valeur doit être traitée comme une couleur".
Actuellement, git configne prend pas en charge ce type de colorisation, mais nous devons faire attention à ne pas s'accroupir trop tôt sur cette option, afin qu'elle
git configpuisse prendre --coloren charge (au sens traditionnel) à l'avenir, si cela est souhaité.
Dans ce patch, nous soutenons --type=<int|bool|bool-or-int|...>en plus --int, --boolet etc.
Cela permet à la prochaine mise à jour ci - dessus à l' appui d' une valeur de l' interrogation couleur avec un défaut via --type=color --default=..., sans dilapidation--color .
Nous conservons le comportement historique de se plaindre lorsque plusieurs --<type>indicateurs de style hérité sont donnés, ainsi que d'étendre cela aux --type=<type>indicateurs de nouveau style en conflit . --int --type=int(et sa paire commutative) ne se plaint pas, mais --bool --type=int(et sa paire commutative) le fait.
Donc avant --boolet --intmaintenant ( documentation ):
--type <type>
' git config' garantira que toute entrée ou sortie est valide sous la ou les contraintes de type données, et canonisera les valeurs sortantes dans<type> la forme canonique.
Les valides <type>incluent:
- '
bool': canonise les valeurs comme " true" ou " false".
- '
int': canoniser les valeurs sous forme de nombres décimaux simples. Un suffixe facultatif de ' k', ' m' ou ' g' provoquera la multiplication de la valeur par 1024, 1048576 ou 1073741824 lors de la saisie.
- '
bool-or-int': canoniser selon ' bool' ou ' int', comme décrit ci-dessus.
- '
path': canoniser en ajoutant un début ~à la valeur de $HOMEet ~userau répertoire personnel de l'utilisateur spécifié. Ce spécificateur n'a aucun effet lors de la définition de la valeur (mais vous pouvez l'utiliser à git config section.variable
~/partir de la ligne de commande pour laisser votre shell faire l'expansion.)
- '
expiry-date': canoniser en convertissant une chaîne de date fixe ou relative en horodatage. Ce spécificateur n'a aucun effet lors de la définition de la valeur.
--bool::
--int::
--bool-or-int::
--path::
--expiry-date::
Historical options for selecting a type specifier. Prefer instead `--type`,
(see: above).
Notez que Git 2.22 (Q2 2019) explique que " git config --type=color ..." est censé remplacer " git config --get-color", mais il y a une légère différence qui n'a pas été documentée, qui est maintenant corrigée.
Voir commit cd8e759 (05 mars 2019) par Jeff King ( peff) .
(Fusionné par Junio C Hamano - gitster- en commit f6c75e3 , 20 mars 2019)
config: la --type=colorsortie du document est une ligne complète
Même si la nouvelle --type=coloroption " " à " git config" est censée être compatible avec l' --get-coloroption " " traditionnelle , contrairement à cette dernière, sa sortie n'est pas une ligne incomplète qui n'a pas le LF à la fin.
Cela le rend cohérent avec la sortie d'autres types comme "git config --type=bool ".
Documentez-le , car il surprend parfois les utilisateurs sans méfiance.
Cela se lit maintenant:
--type=color [--default=<default>]est préférable à --get-color
(mais notez que --get-colorcela supprimera la nouvelle ligne de fin imprimée par
--type=color).
Vous pouvez voir git config --type=boolutilisé avec Git 2.26 (Q1 2020) pour remplacer les git config --boolappels " " dans des exemples de modèles.
Voir commit 81e3db4 (19 janvier 2020) par Lucius Hu ( lebensterben) .
(Fusionné par Junio C Hamano - gitster- en commit 7050624 , 30 janv.2020 )
templates: correction de l'option de type obsolète --bool
Signé par: Lucius Hu
L' --booloption à git-configest marquée comme historique et il est recommandé aux utilisateurs de l'utiliser à la --type=boolplace.
Cette validation remplace toutes les occurrences de --booldans les modèles.
A noter également que, pas d' autres options de type désapprouvée se trouvent, y compris --int, --bool-or-int, --pathou --expiry-date.