Git

git-config last updated in 2.47.1

NOM

git-config - Lire et écrire les options du dépôt et les options globales

SYNOPSIS

git config list [<option-de-fichier>] [<option-d-affichage>] [--includes]
git config get [<option-de-fichier>] [<option-d-affichage>] [--includes] [--all] [--regexp] [--value=<valeur>] [--fixed-value] [--default=<default>] <nom>
git config set [<option-de-fichier>] [--type=<type>] [--all] [--value=<valeur>] [--fixed-value] <nom> <valeur>
git config unset [<option-de-fichier>] [--all] [--value=<valeur>] [--fixed-value] <nom> <valeur>
git config rename-section [<option-de-fichier>] <ancien-name> <nouveau-name>
git config remove-section [<option-de-fichier>] <nom>
git config edit [<option-de-fichier>]
git config [<option-de-fichier>] --get-colorbool <nom> [<stdout-est-tty>]

DESCRIPTION

Vous pouvez interroger/définir/remplacer/annuler les options avec cette commande. Le nom est en fait la section et la clé séparées par un point, et la valeur sera échappée.

Plusieurs lignes peuvent être ajoutées à une option en utilisant l’option --append. Si vous voulez mettre à jour ou annuler une option qui peut se trouver sur plusieurs lignes, un "motif-de-valeur" (qui est une expression régulière étendue, à moins que l’option "--fixed-value" soit donnée) doit être donné. Seules les valeurs existantes qui correspondent au motif sont mises à jour ou annulées. Si vous voulez gérer les lignes qui ne correspondent pas au motif, ajoutez simplement un point d’exclamation devant (voir aussi EXEMPLES), mais notez que cela ne fonctionne que lorsque l’option --fixed-value n’est pas utilisée.

L’option --type=<type> indique à git config de s’assurer que les valeurs entrantes et sortantes peuvent être canonisées sous le <type> donné. Si aucun --type=<type> n’est donné, aucune canonisation ne sera effectuée. Les appelants peuvent annuler un spécificateur --type existant avec --no-type.

Lors de la lecture, les valeurs sont lues par défaut à partir des fichiers de configuration du système, du globaux à l’utilisateur et locaux au dépôt, et les options --system, --global, --local, --worktree et --file <nom-de-fichier> peuvent être utilisées pour indiquer à la commande de lire uniquement à partir de chaque emplacement (voir FICHIERS).

Lors de l’écriture, la nouvelle valeur est écrite dans le fichier de configuration local du dépôt par défaut, et les options --system, --global, --worktree, --file <fichier> peuvent être utilisées pour dire à la commande d’écrire à cet endroit (vous pouvez dire --local mais c’est la valeur par défaut).

Cette commande échouera avec un statut non nul en cas d’erreur. Certains codes de sortie sont :

La section ou la clé n’est pas valide (ret=1),
aucune section ou nom n’a été fourni (ret=2),
le fichier de configuration est invalide (ret=3),
le fichier de configuration ne peut pas être écrit (ret=4),
vous essayez d’annuler une option qui n’existe pas (ret=5),
vous essayez de désactiver/définir une option pour laquelle plusieurs lignes correspondent (ret=5), ou
vous essayez d’utiliser une expression rationnelle non valide (ret=6).

En cas de succès, la commande renvoie le code de sortie 0.

Une liste de toutes les variables de configuration disponibles peut être obtenue en utilisant la commande git help --config.

COMMANDES

list: Lister toutes les variables définies dans le fichier de configuration, avec leurs valeurs.
get: Émet la valeur de la clé spécifiée. Si la clé est présente plusieurs fois dans la configuration, émet la dernière valeur. Si --all est spécifié, émet toutes les valeurs associées à la clé. Retourne le code d’erreur 1 si la clé n’est pas présente.
set: Définir la valeur pour une ou plusieurs options de configuration. Par défaut, cette commande refuse d’écrire des options de configuration multi-valeur. Passer --all remplacera toutes les options de configuration multi-valeur avec la nouvelle valeur, alors que --value= remplacera toutes les options de configuration dont les valeurs correspondent au modèle donné.
unset: Valeur désinitialisée pour une ou plusieurs options de configuration. Par défaut, cette commande refuse de désactiver les clés multi-valeurs. Passer --all dé-enregistrera toutes les options de configuration multi-valeur, alors que --value dé-enregistrera toutes les options de configuration dont les valeurs correspondent au modèle donné.
rename-section: Renommer la section donnée avec un nouveau nom.
remove-section: Supprimer la section indiquée du fichier de configuration.
edit: Ouvrir un éditeur pour modifier le fichier de configuration spécifié ; soit --system, --global, --local (par défaut), --worktree`ou `--file <fichier-config>.

OPTIONS

--replace-all

Le comportement par défaut est de remplacer au maximum une ligne. Ceci remplace toutes les lignes correspondant à la clé (et optionnellement au motif-de-valeur).

--append

Ajoute une nouvelle ligne à l’option sans modifier les valeurs existantes. C’est la même chose que de fournir --value=^$ à set.

--comment <message>

Ajouter un commentaire à la fin des lignes nouvelles ou modifiées.

Si _<message>_ commence avec un ou plusieurs espaces blancs suivis par "#", il est utilisé tel quel. S'il commence par "#", un espace est préfixé avant qu'il ne soit utilisé. Sinon, une chaîne " # " (un espace suivi d'un dièse suivi d'un espace) est préfixée à elle. Et la chaîne résultante est placée immédiatement après la valeur définie pour la variable. Le _ <message>_ ne doit pas contenir de caractères retour-chariot (les commentaires multi-lignes ne sont pas permis).

--all

Avec get, renvoyer toutes les valeurs pour une clé à valeurs multiples.

--regexp

avec get, interpréter le nom comme une expression régulière. La correspondance des expressions régulières est actuellement sensible à la casse et se fait par rapport à une version canonisée de la clé dans laquelle les noms de sections et de variables sont en minuscules, mais pas les noms de sous-sections.

--url=<URL>

Lorsqu’un <nom> en deux parties <section>.<clé> est donné, la valeur de <section>.<URL>.<clé> dont la partie <URL> correspond le mieux à l’URL donnée est retournée (si une telle clé n’existe pas, la valeur de <section>.<clé> est utilisée comme solution de repli). Lorsqu’on donne juste la section comme nom, le faire pour toutes les clés de la <section> et les lister. Renvoie le code d’erreur 1 si aucune valeur n’est trouvée.

--global

Pour l’écriture des options : écrire dans le fichier global ~/.gitconfig plutôt que dans le .git/config du dépôt, écrire dans le fichier $XDG_CONFIG_HOME/git/config si ce fichier existe et que le fichier ~/.gitconfig n’existe pas.

Pour les options de lecture : lire uniquement depuis le ~/.gitconfig global et depuis $XDG_CONFIG_HOME/git/config plutôt que depuis tous les fichiers disponibles.

Voir aussi FICHIERS.

--system

Pour l’écriture des options : écrire dans le $(prefix)/etc/gitconfig niveau système plutôt que dans le .git/config du dépôt.

Pour la lecture des options : lire seulement à partir de $(prefix)/etc/gitconfig niveau système plutôt qu’à partir de tous les fichiers disponibles.

Voir aussi FICHIERS.

--local

Pour l’écriture des options : écrire dans le fichier .git/config du dépôt. C’est le comportement par défaut.

Pour la lecture des options : lire uniquement depuis le .git/config du dépôt plutôt que depuis tous les fichiers disponibles.

Voir aussi FICHIERS.

--worktree

Similaire à --local sauf que $GIT_DIR/config.worktree est lu ou écrit si extensions.worktreeConfig est activé. Sinon, c’est la même chose que --local. Notez que $GIT_DIR est égal à $GIT_COMMON_DIR pour l’arbre-de-travail principal, mais est de la forme $GIT_DIR/worktrees/<id>/ pour les autres arbres-de-travail. Voir git-worktree[1] pour savoir comment activer extensions.worktreeConfig.

-f <fichier-de-config>

--file <fichier-de-config>

Pour l’écriture des options : écrire dans le fichier spécifié plutôt que dans le .git/config du dépôt.

Pour la lecture des options : lire uniquement à partir du fichier spécifié plutôt qu’à partir de tous les fichiers disponibles.

Voir aussi FICHIERS.

--blob <blob>

Similaire à --file mais utiliser le blob donné au lieu d’un fichier. Par exemple, vous pouvez utiliser master:.gitmodules pour lire les valeurs du fichier .gitmodules dans la branche master. Voir la section "SPECIFICATION DE REVISIONS" dans gitrevisions[7] pour une liste plus complète des façons d’épeler les noms de blob.

--fixed-value

Lorsqu’utilisé avec l’argument value-pattern, traiter motif-de-valeur comme une chaîne exacte au lieu d’une expression régulière. Cela limitera les paires nom/valeur qui sont trouvées à celles dont la valeur est exactement égale au motif-de-valeur.

--type <type>

git config s’assurera que toute entrée ou sortie est valide sous la ou les contraintes de type fournies, et canonisera les valeurs sortantes dans la forme canonique de <type>.

Les « <type> » valides comprennent :

bool : canoniser 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 entraînera la multiplication de la valeur par 1024, 1048576 ou 1073741824 lors de la lecture.
bool-ou-int : canoniser selon bool ou int, comme décrit ci-dessus.
path : canonise en ajoutant un ~ à la valeur de $HOME et ~user au 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 utiliser git config section.variable ~/ depuis la ligne de commande pour laisser votre shell faire l’expansion).
expiry-date' : canonisation en convertissant une chaîne de date fixe ou relative en un horodatage. Ce spécificateur n’a aucun effet lors de la définition de la valeur.
color : Lors de l’obtention d’une valeur, la canoniser en la convertissant en une séquence d’échappement de couleur ANSI. Lors de la définition d’une valeur, un contrôle de sanité est effectué pour s’assurer que la valeur donnée peut être canonisée en tant que couleur ANSI, mais elle est écrite telle quelle.

--bool

--int

--bool-or-int

--path

--expiry-date

Options historiques pour la sélection d’un spécificateur de type. Préférez plutôt --type (voir ci-dessus).

--no-type

Défait le spécificateur de type précédemment défini (s’il y en avait un). Cette option demande à git config de ne pas canoniser la variable récupérée. --no-type n’a aucun effet sans --type=<type> ou --<type>.

-z

--null

Pour toutes les options qui produisent des valeurs et/ou des clés, terminer toujours les valeurs par le caractère nul (au lieu d’une nouvelle ligne). Utiliser plutôt le saut de ligne comme délimiteur entre la clé et la valeur. Cela permet une analyse sûre de la sortie sans être confondu, par exemple, avec des valeurs qui contiennent des sauts de ligne.

--name-only

Afficher seulement les noms des variables de configuration pour list ou get.

--show-origin

Augmenter la sortie de toutes les options de configuration interrogées avec le type d’origine (fichier, entrée standard, blob, ligne de commande) et l’origine réelle (chemin du fichier de configuration, ref, ou identifiant du blob si applicable).

--show-scope

Similaire à --show-origin en ce qu’il augmente la sortie de toutes les options de configuration interrogées avec la portée de cette valeur (arbre-de-travail, locale, globale, système, commande).

--get-colorbool <nom> [<stdout-est-tty>]

Trouver le paramètre de couleur pour <nom> (par exemple, color.diff) et affiche "true" ou "false". <stdout-est-tty> devrait être soit "true" soit "false", et est pris en compte lorsque la configuration est "auto". Si <stdout-est-tty> est absent, alors vérifier la sortie standard de la commande elle-même, et sortir avec le statut 0 si la couleur doit être utilisée, ou sortir avec le statut 1 sinon. Lorsque le paramètre de couleur pour <nom> est indéfini, la commande utilise color.ui comme solution de repli.

--[no-]includes

Respecter les directives include.* dans les fichiers de configuration lors de la recherche de valeurs. La valeur par défaut est off lorsqu’un fichier spécifique est donné (par exemple, en utilisant --file, --global, etc) et on lorsqu’on cherche dans tous les fichiers de configuration.

--default <valeur>

Lors de l’utilisation de get, et que la variable demandée n’est pas trouvée, se comporter comme si <valeur> était la valeur assignée à cette variable.

MODES OBSOLÈTES

Les modes suivants ont été dépréciés en faveur des sous-commandes. Il est recommandé de migrer vers la nouvelle syntaxe.

git config <nom>: Remplacé par git config get <nom>.
git config <nom> [<motif-de-valeur>]: Remplacé par git config set [--value=<motif>] <nom> <valeur>.
-l
--list: Remplacé par`git config list`.
--get <nom> [<motif-de-valeur>]: Remplacé par git config get [--value= <motif>] <nom>.
--get-all <nom> [<motif-de-valeur>]: Remplacé par git config get [--value=<motif>] --all <nom>.
--get-regexp <regexp-de-nom>: Remplacé par git config get --all --show-names --regexp <regexp-de-nom>.
--get-urlmatch <nom> <URL>: Remplacé par git config get --all --show-names --url= <URL> <nom>.
--get-color <nom> [<défaut>]: Remplacé par git config get --type=color [--default= <défaut>] <nom>.
--add <nom> <valeur>: Remplacé par git config set --append <nom> <valeur>.
--unset <nom> [<motif-de-valeur>]: Remplacé par git config unset [--value= <motif>] <nom>.
--unset-all <nom> [<motif-de-valeur>]: Remplacé par git config unset [--value=<motif>] --all <nom>.
--rename-section <ancien-nom> <nouveau-nom>: Remplacé par git config rename-section <ancien-nom> <nouveau-nom>.
--remove-section <nom>: Remplacé par git config remove-section <nom>.
-e
--edit: Remplacé par git config edit.

CONFIGURATION

pager.config n’est respecté que lors de l’énumération de la configuration, c’est-à-dire lors de l’utilisation de list ou de l’un des get qui peuvent retourner plusieurs résultats. Le défaut est d’utiliser un pager.

FICHIERS

Par défaut, git config lira les options de configuration à partir de plusieurs fichiers :

$(prefix)/etc/gitconfig: Fichier de configuration au niveau système.
$XDG_CONFIG_HOME/git/config
~/.gitconfig: Fichiers de configuration spécifiques à l’utilisateur. Lorsque la variable d’environnement XDG_CONFIG_HOME n’est pas définie ou est vide, $HOME/.config/ est utilisé comme $XDG_CONFIG_HOME.

Ces fichiers sont également appelés fichiers de configuration "globaux". Si les deux fichiers existent, ils sont lus dans l’ordre donné ci-dessus.
$GIT_DIR/config: Fichier de configuration spécifique au dépôt.
$GIT_DIR/config.worktree: Ceci est optionnel et n’est recherché que si extensions.worktreeConfig est présent dans $GIT_DIR/config.

Vous pouvez aussi fournir des paramètres de configuration additionnels lorsque vous exécutez une commande git en utilisant l’option -c. Voir git[1] pour plus de détails.

Les options seront lues depuis tous ces fichiers lorsqu’ils sont disponibles. Si le fichier de configuration global ou le fichier de configuration du système sont manquants ou illisibles, ils seront ignorés. Si le fichier de configuration du dépôt est manquant ou illisible, git config se terminera avec un code d’erreur non nul. Un message d’erreur sera produit si le fichier n’est pas lisible, mais pas s’il est manquant.

Les fichiers sont lus dans l’ordre indiqué ci-dessus, la dernière valeur trouvée étant prioritaire sur les valeurs lues précédemment. Lorsque plusieurs valeurs peuvent être concaténées, toutes les valeurs d’une clé dans tous les fichiers seront utilisées.

Par défaut, les options sont seulement écrites dans le fichier de configuration spécifique au dépôt. Notez que cela affecte également les options comme set et unset. git config ne modifiera jamais qu’un seul fichier à la fois.

Vous pouvez limiter les sources de configuration qui sont lues ou écrites en spécifiant le chemin d’un fichier avec l’option --file, ou en spécifiant une portée de configuration avec --system, --global, --local, ou --worktree. Pour en savoir plus, voir OPTIONS ci-dessus.

PORTÉES

Chaque source de configuration relève d’une portée de configuration. Les portées sont les suivantes :

Système: $(prefix)/etc/gitconfig
global: $XDG_CONFIG_HOME/git/config

~/.gitconfig
local: $GIT_DIR/config
arbre-de-travail: $GIT_DIR/config.worktree
commande: variables d’environnement GIT_CONFIG_{COUNT,KEY,VALUE} (voir ENVIRONNEMENT ci-dessous)

l’option -c

À l’exception de commande, chaque portée correspond à une option de ligne de commande : --system, --global, --local, --worktree.

Lors de la lecture d’options, la spécification d’une portée ne lira que les options des fichiers de cette portée. Lors de l’écriture d’options, la spécification d’une portée écrira dans les fichiers de cette portée (au lieu du fichier de configuration spécifique au dépôt). Voir OPTIONS ci-dessus pour une description complète.

La plupart des options de configuration sont respectées quelle que soit la portée dans laquelle elles sont définies, mais certaines options ne sont respectées que dans certaines portées. Consultez la documentation de l’option concernée pour plus de détails.

Configuration protégée

La configuration protégée fait référence aux portées système, global et commande. Pour des raisons de sécurité, certaines options ne sont respectées que lorsqu’elles sont spécifiées en configuration protégée, et ignorées dans le cas contraire.

Git traite ces portées comme si elles étaient contrôlées par l’utilisateur ou un administrateur de confiance. Ceci est dû au fait qu’un attaquant qui contrôle ces portées peut causer des dommages substantiels sans utiliser Git, il est donc supposé que l’environnement de l’utilisateur protège ces portées contre les attaquants.

ENVIRONNEMENT

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Prendre la configuration à partir des fichiers donnés au lieu de la configuration globale ou au niveau du système. Voir git[1] pour plus de détails.
GIT_CONFIG_NOSYSTEM: Si l’on veut éviter de lire les paramètres du fichier $(prefix)/etc/gitconfig du système. Voir git[1] pour plus de détails.

Voir aussi FICHIERS.

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>: Si GIT_CONFIG_COUNT est défini comme un nombre positif, toutes les paires d’environnement GIT_CONFIG_KEY_<n> et GIT_CONFIG_VALUE_<n> jusqu’à ce nombre seront ajoutées à la configuration d’exécution du processus. Les paires de configurations sont indexées à zéro. Toute clé ou valeur manquante est traitée comme une erreur. Un GIT_CONFIG_COUNT vide est traité de la même manière que GIT_CONFIG_COUNT=0, c’est-à-dire qu’aucune paire n’est traitée. Ces variables d’environnement remplaceront les valeurs dans les fichiers de configuration, mais seront remplacées par toute option explicite passée via git -c.

C’est utile dans les cas où vous voulez lancer plusieurs commandes git avec une configuration commune mais ne pouvez pas dépendre d’un fichier de configuration, par exemple lorsque vous écrivez des scripts.
GIT_CONFIG: Si aucune option --file n’est fournie à git config, utiliser le fichier donné par GIT_CONFIG comme s’il était fourni via --file. Cette variable n’a aucun effet sur les autres commandes Git, et est surtout destinée à assurer une compatibilité historique ; il n’y a généralement aucune raison de l’utiliser à la place de l’option --file.

EXEMPLES

Avec un .git/config comme ceci :

#
# C'est le fichier de configuration, et
# un caractère '#' ou ';' indique
# un commentaire
#

; variables de base
[core]
	; ne pas faire confiance au mode des fichiers
	filemode = false

; Notre algorithme de diff
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

; paramètres du proxy
[core]
	gitproxy=proxy-command for kernel.org
	gitproxy=default-proxy ; pour tout le reste

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
	cookieFile = /tmp/cookie.txt

vous pouvez mettre le filemode à true avec

% git config set core.filemode true

Les entrées hypothétiques de la commande proxy ont en fait un postfix pour discerner l’URL à laquelle elles s’appliquent. Voici comment changer l’entrée pour kernel.org en "ssh".

% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'

Cela permet de s’assurer que seule la paire clé/valeur de kernel.org est remplacée.

Pour supprimer l’entrée pour les renommages, faites

% git config unset diff.renames

Si vous voulez supprimer une entrée pour un multivar (comme core.gitproxy ci-dessus), vous devez fournir une regex correspondant à la valeur d’exactement une ligne.

Pour demander la valeur d’une clef donnée, faites

% git config get core.filemode

ou, pour interroger un multivar :

% git config get --value="for kernel.org$" core.gitproxy

Si vous voulez connaître toutes les valeurs d’un multivar, faites :

% git config get --all --show-names core.gitproxy

Si vous aimez vivre dangereusement, vous pouvez remplacer tout core.gitproxy par une nouvelle valeur avec

% git config set --all core.gitproxy ssh

Cependant, si vous voulez seulement remplacer la ligne pour le proxy par défaut, c’est-à-dire celui sans postfixe "for …", faites quelque chose comme ceci :

% git config set --value='! for ' core.gitproxy ssh

Pour ne faire correspondre que les valeurs comportant un point d’exclamation, vous devez

% git config set --value='[!]' section.key value

Pour ajouter un nouveau proxy, sans modifier aucun des proxy existants, utilisez

% git config set --append core.gitproxy '"proxy-command" for exemple.com'

Un exemple d’utilisation de la couleur personnalisée de la configuration dans votre script :

#!/bin/sh
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
RESET=$(git config get --type=color --default="reset" "")
echo "${WS}votre color d'espace et bleu sont échangées${RESET}"

Pour les URLs dans https://weak.example.com, http.sslVerify est mis à false, alors qu’il est mis à true pour toutes les autres :

% git config get --type=bool --url=https://bon.exemple.com http.sslverify
true
% git config get --type=bool --url=https://faible.exemple.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt
http.sslverify false

FICHIER DE CONFIGURATION

Le fichier de configuration Git contient un certain nombre de variables qui affectent le comportement des commandes Git. Les fichiers .git/config et éventuellement config.worktree (voir la section "FICHIER DE CONFIGURATION" de git-worktree[1]) dans chaque dépôt sont utilisés pour stocker la configuration de ce dépôt, et $HOME/.gitconfig est utilisé pour stocker une configuration par utilisateur comme valeurs de repli pour le fichier .git/config. Le fichier /etc/gitconfig peut être utilisé pour stocker une configuration par défaut pour l’ensemble du système.

Les variables de configuration sont utilisées à la fois par la plomberie Git et les commandes de porcelaine. Les variables sont divisées en sections, dans lesquelles le nom de variable entièrement qualifié de la variable elle-même est le dernier segment séparé par un point et le nom de la section est tout ce qui précède le dernier point. Les noms de variables sont insensibles à la casse, n’autorisent que les caractères alphanumériques et -, et doivent commencer par un caractère alphabétique. Certaines variables peuvent apparaître plusieurs fois ; on dit alors que la variable est multivaluée.

Syntaxe

La syntaxe est assez souple et permissive. Les caractères d’espaces blancs, qui dans ce contexte sont les caractères espace (SP) et les tabulations horizontales (HT) sont généralement ignorés. Les caractères # et  ; commencent les commentaires à la fin de la ligne. Les lignes blanches sont ignorées.

Le fichier se compose de sections et de variables. Une section commence par le nom de la section entre crochets et se poursuit jusqu’au début de la section suivante. Les noms de section ne sont pas sensibles à la casse. Seuls les caractères alphanumériques, - et . sont autorisés dans les noms de section. Chaque variable doit appartenir à une section, ce qui signifie qu’il doit y avoir un en-tête de section avant le premier paramétrage d’une variable.

Les sections peuvent être divisées en sous-sections. Pour commencer une sous-section, mettez son nom entre guillemets, séparé du nom de la section par un espace, dans l’en-tête de la section, comme dans l’exemple ci-dessous :

	[section "sous-section"]

Les noms de sous-sections sont sensibles à la casse et peuvent contenir n’importe quel caractère, à l’exception du saut de ligne et de l’octet nul. Les guillemets " et les barres obliques inverses peuvent être inclus en les échappant sous la forme \" et \\, respectivement. Les barres obliques inverses précédant d’autres caractères sont supprimées lors de la lecture ; par exemple, \t est lu comme t et \0 est lu comme 0. Les en-têtes de section ne peuvent pas s’étendre sur plusieurs lignes. Les variables peuvent appartenir directement à une section ou à une sous-section donnée. Vous pouvez avoir une [section] si vous avez [section sous-section], mais vous n’en avez pas besoin.

Il existe également une syntaxe [section.sous-section] obsolète. Avec cette syntaxe, le nom de la sous-section est converti en minuscules et est également comparé en tenant compte de la casse. Ces noms de sous-sections suivent les mêmes restrictions que les noms de sections.

Toutes les autres lignes (et le reste de la ligne après l’en-tête de section) sont reconnues comme des variables de réglage, sous la forme nom = valeur (ou simplement nom, qui est un raccourci pour dire que la variable est le booléen « vrai »). Les noms des variables sont insensibles à la casse, n’autorisent que les caractères alphanumériques et -, et doivent commencer par un caractère alphabétique.

Les caractères d’espace blanc entourant le nom, = et valeur sont supprimés. Les caractères internes de l’espace blanc dans la valeur sont conservés verbatim. Les commentaires commençant par # ou ; et s’étendant jusqu’à la fin de la ligne sont supprimés. Une ligne qui définit une valeur peut être poursuivie jusqu’à la ligne suivante en la finissant avec un backslash (\) ; les caractères backslash et de fin de ligne sont supprimés.

Si <valeur> doit contenir des caractères d’espace blancs au début ou à la fin, elle doit être citée en double guillemet (" ). À l ' intérieur des doubles guillemets, les caractères guillemet (") et barre inversée (\) doivent être échappés : utilisez \" pour " et \\ pour \.

Les séquences d’échappement suivantes (en plus de \" et \\) sont reconnues : \n pour le caractère de retour à la ligne (NL), \t pour la tabulation horizontale (HT, TAB) et \b pour l’espacement arrière (BS). Les autres séquences d’échappement de caractères (y compris les séquences d’échappement octales) ne sont pas valides.

Inclusions

Les sections include et includeIf vous permettent d’inclure des directives de configuration provenant d’une autre source. Ces sections se comportent de manière identique, à l’exception des sections includeIf qui peuvent être ignorées si leur condition n’est pas évaluée comme vraie ; voir "Inclusions conditionnelles" ci-dessous.

Vous pouvez inclure un fichier de configuration à partir d’un autre en définissant la variable spéciale include.path (ou includeIf.*.path) au nom du fichier à inclure. La variable prend un nom de chemin comme valeur, et est soumise à l’expansion tilde. Ces variables peuvent être données plusieurs fois.

Le contenu du fichier inclus est inséré immédiatement, comme s’il avait été trouvé à l’endroit de la directive d’inclusion. Si la valeur de la variable est un chemin relatif, le chemin est considéré comme relatif au fichier de configuration dans lequel la directive include a été trouvée. Voir ci-dessous pour des exemples.

Inclusions conditionnelles

Vous pouvez inclure conditionnellement un fichier de configuration provenant d’un autre fichier en définissant une variable includeIf.<condition>.path au nom du fichier à inclure.

La condition commence par un mot-clé suivi d’un deux-points et de quelques données dont le format et la signification dépendent du mot-clé. Les mots-clés pris en charge sont les suivants :

gitdir

Les données qui suivent le mot-clé gitdir: sont utilisées comme modèle de motif glob. Si l’emplacement du répertoire .git correspond au motif, la condition d’inclusion est remplie.

L’emplacement de .git peut être découvert automatiquement ou provenir de la variable d’environnement $GIT_DIR. Si le dépôt est découvert automatiquement via un fichier .git (par exemple à partir de sous-modules ou d’un arbre de travail lié), l’emplacement du .git sera l’emplacement final où se trouve le répertoire .git, et non pas où le fichier .git est.

Le motif peut contenir des caractères génériques de globbing standard et deux autres, **/ et /**, qui peuvent correspondre à plusieurs composants de chemin d’accès. Veuillez consulter gitignore[5] pour plus de détails. Pour plus de commodité :

Si le motif commence par ~/, ~ sera remplacé par le contenu de la variable d’environnement HOME.
Si le motif commence par './, il est remplacé par le répertoire contenant le fichier de configuration actuel.
Si le motif ne commence pas par ~/, ./ ou /, **/ sera automatiquement ajouté en préfixe. Par exemple, le motif foo/bar devient **/foo/bar et correspondra à tout/chemin/vers/foo/bar.
Si le motif se termine par /, ** sera automatiquement ajouté. Par exemple, le motif foo/ devient foo/**. En d’autres termes, il correspond à foo et à tout ce qui se trouve à l’intérieur, de manière récursive.

gitdir/i

C’est la même chose que gitdir sauf que la correspondance se fait sans tenir compte de la casse (par exemple sur les systèmes de fichiers insensibles à la casse)

onbranch

Les données qui suivent le mot-clé onbranch: sont considérées comme un motif avec des jokers standard et deux autres, **/ et /**, qui peuvent correspondre à plusieurs composants de chemin. Si nous nous trouvons dans un arbre de travail où le nom de la branche actuellement extraite correspond au motif, la condition d’inclusion est remplie.

Si le motif se termine par /, ** sera automatiquement ajouté. Par exemple, le motif foo/ devient foo/**. En d’autres termes, il correspond à toutes les branches qui commencent par foo/. Ceci est utile si vos branches sont organisées de manière hiérarchique et que vous souhaitez appliquer une configuration à toutes les branches de cette hiérarchie.

hasconfig:remote.*.url:

Les données qui suivent ce mot-clé sont considérées comme un motif avec des jokers standard et deux autres, **/ et /**, qui peuvent correspondre à plusieurs composants. La première fois que ce mot-clé est vu, le reste des fichiers de configuration sera analysé pour trouver des URL distants (sans appliquer aucune valeur). S’il exist au moint une URL distante qui correspond au motif, la condition d’inclusion est remplie.

Les fichiers inclus par cette option (directement ou indirectement) ne sont pas autorisés à contenir des URL distants.

Notez que contrairement aux autres conditions includeIf, la résolution de cette condition repose sur des informations qui ne sont pas encore connues au moment de la lecture de la condition. Un cas d’utilisation typique est que cette option est présente dans une configuration de niveau système ou global, et que l’URL distante se trouve dans une configuration de niveau local ; d’où la nécessité d’effectuer un balayage préalable lors de la résolution de cette condition. Afin d’éviter le problème de la poule et de l’œuf, dans lequel les fichiers potentiellement inclus peuvent affecter le fait que ces fichiers soient potentiellement inclus ou non, Git brise le cycle en interdisant à ces fichiers d’affecter la résolution de ces conditions (donc en leur interdisant de déclarer des URL distantes).

Quant au nom de ce mot-clé, c’est pour des raisons de compatibilité avec un schéma de nommage qui supporte des conditions d’inclusion plus basées sur des variables, mais actuellement Git ne supporte que le mot-clé exact décrit ci-dessus.

Quelques notes supplémentaires sur la correspondance via gitdir et gitdir/i :

Les liens symboliques dans $GIT_DIR ne sont pas résolus avant la correspondance.
Les versions symlink et realpath des chemins seront comparées en dehors de $GIT_DIR. Par exemple, si ~/git est un lien symbolique vers /mnt/stockage/git, gitdir:~/git et gitdir:/mnt/stockage/git correspondront tous deux.

Ce n’était pas le cas dans la version initiale de cette fonctionnalité dans la v2.13.0, qui ne correspondait qu’à la version realpath. La configuration qui veut être compatible avec la version initiale de cette fonctionnalité doit soit spécifier uniquement la version realpath, soit les deux versions.
Notez que "../" n’est pas spécial et correspondra littéralement, ce qui est peu probablement ce que vous voulez.

Exemple

# Variables core
[core]
	; Ne pas se fier au modes des fichiers
	filemode = false

# Notre algorithme de diff
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

[branch "devel"]
	remote = origin
	merge = refs/heads/devel

# Réglages proxy
[core]
	gitProxy="ssh" for "kernel.org"
	gitProxy=default-proxy ;pour le reste

[include]
	path = /chemin/vers/foo.inc ; inclure par chemin absolu
	path = foo.inc ; trouver "foo.inc" relativement au fichier actuel
	path = ~/foo.inc ; trouver "foo.inc" dans votre répertoire `$HOME`

; inclure si $GIT_DIR est /chemin/vers/foo/.git
[includeIf "gitdir:/chemin/vers/foo/.git"]
	path = /chemin/vers/foo.inc

; inclure tous les dépôts dans /chemin/vers/groupe
[includeIf "gitdir:/chemin/vers/groupe"]
	path = /chemin/vers/foo.inc

; inclure pour tous les dépôts à l'intérieur de $HOME/vers/groupe
[includeIf "gitdir:~/vers/groupe/"]
	path = /chemin/vers/foo.inc

les chemins relatifs sont toujours relatifs au fichier
; incluant (si la condition est vraie) ; leur emplacement n'est pas
; affecté par la condition
[includeIf "gitdir:/chemin/vers/groupe/"]
	path = foo.inc

; n'inclure que si nous sommes dans un arbre de travail où foo-branch
; actuellement extrait
[includeIf "onbranch:foo-branch"]
	path = foo.inc

; inclure seulement si un fichier distant avec l'URL donnée existe (note
; qu'une telle URL peut être fournie plus tard dans un fichier ou dans un fichier
; ou dans un fichier lu après la lecture de ce fichier, comme dans cet exemple).
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
	path = foo.inc
[remote "origin"]
	url = https://example.com/git

Valeurs

Les valeurs de nombreuses variables sont traitées comme une simple chaîne de caractères, mais il existe des variables qui prennent des valeurs de types spécifiques et il existe des règles quant à leur orthographe.

booléen

Lorsqu’une variable prend une valeur booléenne, de nombreux synonymes sont acceptés pour vrai et faux ; ils sont tous insensibles à la casse.

true: Les littéraux booléens pour vrai sont yes, on, true et 1. De plus, une variable définie sans =<valeur> est considérée comme vraie.
faux: Les littéraux booléens faux sont no, off, false, 0 et la chaîne vide.

Lors de la conversion d’une valeur sous sa forme canonique en utilisant le spécificateur de type --type=bool, git config s’assurera que la sortie est "true" ou "false" (écrit en minuscules).

Entier

La valeur de nombreuses variables qui spécifient différentes tailles peut être suffixée par k, M, … pour signifier « multiplier le nombre par 1024 », « par 1024x1024 », etc.

color

La valeur d’une variable qui prend une couleur est une liste de couleurs (au plus deux, une pour le premier plan et une pour l’arrière-plan) et les attributs (autant que vous le souhaitez), séparés par des espaces.

Les couleurs de base acceptées sont normal, black, red, green, yellow, blue, magenta, cyan, white et default. La première couleur donnée est le premier plan ; la seconde est l’arrière-plan. Toutes les couleurs de base, sauf la couleur normal et default, ont une variante claire qui peut être spécifiée en préfixant la couleur par bright, comme brightred.

La couleur normal ne modifie pas la couleur. C’est la même chose qu’une chaîne vide, mais elle peut être utilisée comme couleur de premier plan lorsqu’on spécifie une couleur d’arrière-plan seule (par exemple, "normal red").

La couleur default réinitialise explicitement la couleur par défaut du terminal, par exemple pour spécifier un fond clair. Bien que cela varie d’un terminal à l’autre, ce n’est généralement pas la même chose que de définir un "blanc noir".

Les couleurs peuvent également être données en tant que nombres entre 0 et 255 ; ceux-ci utilisent le mode ANSI 256 couleurs (mais notez que certains terminaux ne peuvent pas prendre en charge cela). Si votre terminal le prend en charge, vous pouvez également spécifier des valeurs RGB 24 bits en hexadécimal, comme #ff0ab3, ou des valeurs RGB de 12 bits comme #f1b, qui est équivalent à la couleur 24 bits #ff11bb.

Les attributs acceptés sont bold, dim, ul, blink, reverse, italic, et strike (pour les lettres barrées ou "surlignées"). La position de tout attribut par rapport aux couleurs (avant, après ou entre les deux) n’a pas d’importance. Des attributs spécifiques peuvent être désactivés en les préfixant par no ou no- (par exemple, noreverse, no-ul, etc.).

Le pseudo-attribut reset réinitialise toutes les couleurs et tous les attributs avant d’appliquer la coloration spécifiée. Par exemple, reset green aura pour résultat un avant-plan vert et un arrière-plan par défaut sans aucun attribut actif.

Une chaîne de couleur vide ne produit aucun effet de couleur. Cela peut être utilisé pour éviter de colorer des éléments spécifiques sans désactiver complètement la couleur.

Pour les étiquettes de couleur prédéfinies de git, les attributs sont censés être réinitialisés au début de chaque élément de la sortie colorée. Ainsi, mettre color.decorate.branch à black peindra le nom de cette branche en un simple black, même si la chose précédente sur la même ligne de sortie (par exemple, ouvrir une parenthèse avant la liste des noms de branches dans la sortie de log --decorate) est mise à être peinte avec bold ou un autre attribut. Cependant, les formats de log personnalisés peuvent faire une coloration plus compliquée et plus stratifiée, et les formes inversées peuvent être utiles dans ce cas.

nom-de-chemin

Une variable qui prend la valeur d’un nom de chemin peut recevoir une chaîne de caractères commençant par "~/" ou "~user/", et l’expansion tilde habituelle se fait sur une telle chaîne : ~/ est développée à la valeur de $HOME, et ~user/ au répertoire personnel de l’utilisateur spécifié.

Si un chemin commence par %(prefix)/, le reste est interprété comme un chemin relatif au "préfixe d’exécution" de Git, c’est-à-dire relatif à l’emplacement où Git lui-même a été installé. Par exemple, %(prefix)/bin/ fait référence au répertoire dans lequel se trouve l’exécutable Git lui-même. Si Git a été compilé sans le support des préfixes d’exécution, le préfixe compilé sera substitué à la place. Dans le cas peu probable où un chemin littéral doit être spécifié et ne doit pas être étendu, il doit être préfixé par ./, comme ceci : ./%(préfixe)/bin.

Variables

Notez que cette liste n’est pas exhaustive et n’est pas nécessairement complète. Pour les variables spécifiques à une commande, vous trouverez une description plus détaillée dans la page du manuel appropriée.

D’autres outils liés à git peuvent utiliser et utilisent leurs propres variables. Lorsque vous inventez de nouvelles variables à utiliser dans votre propre outil, assurez-vous que leurs noms n’entrent pas en conflit avec ceux qui sont utilisés par Git lui-même et d’autres outils populaires, et décrivez-les dans votre documentation.

Warning

Missing fr/config/add.txt