Les données qui suivent le mot-clé gitdir`et deux points 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.

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)

Les données qui suivent le mot-clé onbranch et deux points 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.

Les données qui suivent ce mot-clé et deux points 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 moins une URL distante qui correspond au motif, la condition d’inclusion est remplie.

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

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.

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.

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é.

Indique à git add de continuer à ajouter des fichiers lorsque certains fichiers ne peuvent pas être ajoutés en raison d’erreurs d’indexation. Équivalent à l’option --ignore-errors de git-add[1]. add.ignore-errors est obsolète, car il ne suit pas la convention de nom habituelle pour les variables de configuration.

Le nom du distant à créer lors du clonage d’un dépôt. Par défaut origin. Il peut être surchargé en passant l’option de ligne de commande --origin à git-clone[1].

Rejeter le clonage d’un dépôt s’il s’agit d’un dépôt superficiel ; cela peut être surchargé en passant l’option --reject-shallow sur la ligne de commande. Voir git-clone[1]

Si un filtre de clone partiel est fourni (voir --filter dans git-rev-list[1]) et --recurse-submodules est utilisé, appliquer également le filtre aux sous-modules.

Ce paramètre surcharge la valeur par défaut de l’option --cleanup dans git commit. See git-commit[1] for details. Changer la valeur par défaut peut être utile lorsque vous voulez toujours garder des lignes qui commencent par le caractère de commentaire (core.commentChar, par défaut #) dans votre message de journal, auquel cas vous feriez git config commit.cleanup whitespace (notez que vous devrez supprimer les lignes d’aide qui commencent par le caractère de commentaire dans le modèle de journal de commit vous-même, si vous le faites).

Un booléen pour spécifier si tous les commits doivent être signés GPG. L’utilisation de cette option lors d’opérations telles que le rebasage peut entraîner un grand nombre de signature de commits. Il peut être pratique d’utiliser un agent pour éviter de taper votre mot de passe GPG plusieurs fois.

Un booléen pour activer/désactiver l’inclusion d’information de status dans le modèle de message de validation lors de l’utilisation d’un éditeur pour préparer le message de validation. Valeur par défaut à true.

Spécifier le nom de chemin d’un fichier à utiliser comme modèle pour de nouveaux messages de commit.

Un booléen ou un int pour préciser le niveau de verbosité avec git commit. See git-commit[1] for details.

Lors de l’utilisation de git diff pour comparer avec les fichiers d’arbres de travail, ne pas considérer les modifications des statistiques seulement comme modifiées. Au lieu de cela, lancer silencieusement git update-index --refresh pour mettre à jour l’information de stat cachée pour les chemins dont le contenu dans l’arbre de travail correspond au contenu dans l’index. Cette option est par défaut vraie. Notez que cela n’affecte que la commande porcelaine git diff, et pas les commandes diff de niveau inférieur comme git diff-files.

Une liste séparée par virgules des paramètres --dirstat spécifiant le comportement par défaut de l’option --dirstat pour git-diff[1] et compagnie. Les valeurs par défaut peuvent être surchargées sur la ligne de commande (en utilisant --dirstat=<param>,...). Les valeurs par défaut (lorsqu’elles ne sont pas modifiée par diff.dirstat) sont changes,noncumulative,3. Les paramètres suivants sont disponibles :

Limiter la largeur de la partie nom de fichier dans la sortie de --stat. Si défini, s’applique à toutes les commandes générant une sortie --stat sauf format-patch.

Limiter la largeur de la partie graphique dans la sortie --stat. Si défini, s’applique à toutes les commandes générant une sortie --stat sauf format-patch.

Générer des diffs avec <n> lignes de contexte au lieu des trois par défaut. Cette valeur est surchargée par l’option -U.

Afficher le contexte entre des sections de diff, jusqu’au nombre spécifié de lignes, fusionnant de ce fait les sections qui sont proches. Cette valeur sert de valeur par défaut pour l’option de ligne de commande --inter-hunk-context.

Si cette variable de configuration est définie, la génération diff n’est pas effectuée en utilisant la machinerie de diff interne, mais en utilisant la commande donnée. Peut être remplacé par la variable d’environnement GIT_EXTERNAL_DIFF. La commande est appelée avec des paramètres décrits sous "Diffs git" dans git[1]. Remarque : si vous voulez utiliser un programme de diff externe uniquement sur un sous-ensemble de vos fichiers, vous pouvez utiliser gitattributes[5].

Si cette valeur booléenne est définie à true alors la commande diff.external devrait retourner le code de sortie 0 si elle considère que les fichiers d’entrée sont égaux ou 1 si elle les juge différents, comme diff(1). Si la valeur est définie à false, qui est la valeur par défaut, alors la commande est censée retourner le code de sortie 0 indépendamment de l’égalité. Tout autre code de sortie fait que Git signale une erreur fatale.

Définit la valeur par défaut de --ignore-submodules. Notez que cela n’affecte que la commande porcelaine git diff, et pas les commandes diff de niveau inférieur comme git diff-files. git checkout et git switch honorent également ce réglage lors de l’affichage des modifications non enregistrées. Le régler à all désactive le résumé par sous-module affiché par git commit et git status quand status.submoduleSummary est réglé à moins qu’il soit surchargé en utilisant l’option de ligne de commande --ignore-submodules. Les commandes git submodule ne sont pas affectées par ce paramètre. Par défaut, ce paramètre vaut untracked pour que tous les sous-modules non suivis soient ignorés.

Si elle est définie, git diff utilise une paire de préfixes qui est différente de la norme a/ et b/ selon ce qui est comparé. Lorsque cette configuration est en vigueur, la sortie diff inversée échange également l’ordre des préfixes :

Si défini, git diff ne montre aucun préfixe source ou destination.

Si défini, git diff utilise ce préfixe de source. Par défaut, a/.

Si défini, git diff utilise ce préfixe de destination. Par défaut b/.

Si l’option est définie à true, git diff n’affiche pas les modifications à l’extérieur du répertoire et indique les noms de chemin par rapport au répertoire courant.

Fichier indiquant comment ordonner des fichiers dans une diff. Voir l’option -O de git-diff[1] pour plus de détails. Si diff.orderFile est un nom de chemin relatif, il est traité comme relatif au sommet de l’arbre de travail.

Le nombre de fichiers à considérer dans la partie exhaustive de la détection de copie/renommage ; équivalent à l’option -l de git diff. Si elle n’est pas définie, la valeur par défaut est actuellement 1000. Ce réglage n’a aucun effet si la détection de renommage est désactivée.

Quand et comment Git détecte des renommages. Si défini à false, la détection de renommage est désactivée. Si défini à true, la détection de renommage de base est activée . Si défini à copies ou copy, Git détectera également les copies. Par défaut à true. Notez que cela affecte seulement la porcelaine git diff comme git-diff[1] et git-log[1], et non les commandes de niveau inférieur comme git-diff-files[1].

Un booléen pour inhiber le comportement standard de l’impression d’un espace avant chaque ligne de sortie vide. Par défaut à false.

Spécifier le format dans lequel les différences dans les sous-modules sont affichées. Le format short (court) est utilisé. Ce format n’affiche que le nom des commits du début et de la fin de la plage. Le format log liste les commits dans la plage comme le fait summary de git-submodule[1]. Le format diff affiche une diff en ligne des modifications dans le sous-module. Vaut par défaut short.

Un expression rationnelle étendue POSIX utilisée pour déterminer ce qui est un « mot » lors de l’exécution de calculs de différence mot par mot. Les séquences de caractères qui correspondent à l’expression régulière sont des "mots", tous les autres caractères sont des espaces blancs ignorables.

La commande personnalisée de pilote de diff. Voir gitattributes[5] pour plus de détails.

Si cette valeur booléenne est définie à true, la commande diff.<pilote>.command devrait retourner le code de sortie 0 si elle considère que les fichiers d’entrée sont égaux ou 1 si elle les considère différents, comme diff(1). Si la valeur est définie à false, qui est la valeur par défaut, alors la commande est censée retourner le code de sortie 0 indépendamment de l’égalité. Tout autre code de sortie fait que Git signale une erreur fatale.

L’expression rationnelle que le pilote de diff devra utiliser pour reconnaître l’en-tête d’une section. Un motif pré-intégré peut également être utilisé. Voir gitattributes[5] pour les détails.

Réglez cette option à true pour indiquer au pilote de diff de traiter les fichiers comme binaires. Voir gitattributes[5] pour plus de détails.

La commande que le pilote de diff devra appeler pour générer la version textuelle d’un fichier. Le résultat de la conversion est utilisé pour générer un diff humainement lisible. Voir gitattributes[5] pour les détails.

L’expression rationnelle que le pilote de diff devrait utiliser pour séparer les mots dans une ligne. Voir gitattributes[5] pour plus de détails.

Réglez cette option à true pour indiquer au pilote de diff de mettre en les sorties de conversion en texte. Voir gitattributes[5] pour plus de détails.

Réglez cette option à false (faux) pour désactiver l’heuristique par défaut qui décale les limites des sections de diff pour rendre les rustines plus faciles à lire.

Choisir un algorithme de diff. Les variantes sont comme suit :

Surligner les erreurs d’espace dans les lignes context (contexte), old (ancien) et new (nouveau) du diff. Des valeurs multiples sont séparées par des virgules, none réinitialise les valeurs précédentes, default réinitialise la liste à new et all est un raccourci pour old,new,context. Les erreurs d’espace sont colorés avec color.diff.whitespace. L’option de la ligne de commande --ws-error-highlight=<type> surcharge ce réglage.

S’il est réglé à un <mode> valide ou à true, les lignes déplacées dans une diff sont colorées différemment. Pour les détails des modes valides voir --color-moved dans git-diff[1]. S’il est défini simplement true le mode de couleur par défaut sera utilisé. Quand la valeur est false, les lignes déplacées ne sont pas colorées.

Lorsque les lignes déplacées sont colorées en utilisant par exemple le réglage diff.colorMoved, cette option contrôle le mode de traitement des espaces. Pour les détails sur les modes valides voir --color-moved-ws dans git-diff[1].

Spécifier le répertoire depuis lequel les modèles vont être copiés. (See the "TEMPLATE DIRECTORY" section of git-init[1].)

Permet de remplacer le nom de la branche par défaut, par exemple lors de l’initialisation d’un nouveau dépôt.

Permet de remplacer le format par défaut pour les nouveaux dépôts. Voir --object-format= dans git-init[1]. Tant l’option de ligne de commande que la variable d’environnement `GIT_DEFAULT_HASH ont préséance sur cette configuration.

Permet de remplacer le format de stockage par défaut pour les nouveaux dépôts. Voir --ref-format= dans git-init[1]. Tant l’option de ligne de commande que la variable d’environnement GIT_DEFAULT_REF_FORMAT ont préséance sur cette configuration.

Spécifier le style dans lequel les sections en conflit sont écrites dans les fichiers de l’arbre de travail lors de la fusion. La valeur par défaut est "merge", qui affiche un marqueur de conflit <<<<<<<, les modifications faites par un côté, un marqueur ==========, les modifications faites par l’autre côté, et ensuite un marqueur >>>>>>>. Un style alternatif, "diff3", ajoute un marqueur ||||||| et le texte original avant le marqueur ========. Le style "merge" tend à produire des régions de conflit plus petites que diff3, à la fois à cause de l’exclusion du texte original, et parce que lorsqu’un sous-ensemble de lignes correspondent des deux côtés, elles sont simplement retirées de la région de conflit. Un autre style alternatif, "zdiff3" est similaire à diff3 mais supprime les lignes correspondantes des deux côtés de la région de conflit lorsque ces lignes correspondantes apparaissent près du début ou de la fin d’une région de conflit.

Si la fusion est appelée sans aucun argument de commit, fusionner les branches amont configurées pour la branche courante en utilisant leurs dernières valeurs observées stockées dans leurs branches de suivi à distance. Les valeurs de branch.<branche-courante>.merge qui nomment les branches distantes nommées par branch.<branche-courante>.remote sont consultées, puis elles sont mappées via remote.<distant>.fetch vers leurs branches de suivi à distance correspondantes, et les extrémités de ces branches de suivi sont fusionnées. La valeur par défaut est true.

Par défaut, Git ne crée pas de commit de fusion supplémentaire lors de la fusion d’un commit descendant du commit courant. Au lieu de cela, le sommet de la branche courante est avancé rapidement. Quand elle est définie à false, cette variable indique à Git de créer un commit de fusion supplémentaire dans un tel cas (équivalent à donner l’option --no-ff de la ligne de commande). Lorsqu’il est défini à only, seules ces fusions en avance rapide sont autorisées (ce qui équivaut à donner l’option --ff-only depuis la ligne de commande).

Si vrai, c’est équivalent à l’option de ligne de commande --verify-signatures. Voir git-merge[1] pour plus de détails.

En plus des noms des branches, remplir le message de validation avec le texte de description des branches qui leur est associé. Désactivé par défaut (valeur false).

En plus des noms de branches, remplir le message de validation avec au maximum le nombre spécifié de descriptions d’une ligne des commits réels fusionnés. Désactivé par défaut (valeur false), et vaut 20 si true.

En ajoutant à cette variable de configuration à valeurs multiples un motif qui correspond aux noms des branches d’intégration, le message de fusion par défaut calculé pour les fusions dans ces branches d’intégration omettra "into <nom de branche>" dans son titre.

Le nombre de fichiers à prendre en compte dans la partie restante de la détection de renommage lors d’une fusion ; s’il n’est pas spécifié, la valeur par défaut est celle de diff.renameLimit. Si ni merge.renameLimit ni diff.renameLimit ne sont spécifiés, la valeur par défaut est 7000. Ce réglage n’a aucun effet si la détection de renommage est désactivée.

Indique si Git doit détecter les renommages. S’il est défini à false, la détection de renommage est désactivée. S’il est défini à true, la détection de renommage de base est activée. La valeur par défaut est diff.renames.

Que Git détecte les renommages de répertoire, affectant ce qui arrive au moment de la fusion à de nouveaux fichiers ajoutés à un répertoire d’un côté de l’historique lorsque ce répertoire a été renommé de l’autre côté de l’historique. Les valeurs possibles sont :

Indiquer à Git que la représentation canonique des fichiers dans le dépôt a changé au fil du temps (par exemple, les premiers commits enregistrent les fichiers avec des fins de ligne CRLF, mais les plus récents utilisent des fins de ligne LF). Dans un tel dépôt, pour chaque fichier où une fusion à trois branche est nécessaire, Git peut convertir les données enregistrées dans les commits en une forme canonique avant d’effectuer une fusion pour réduire les conflits inutiles. Pour plus d’informations, voir la section "Fusionner des branches avec des attributs d’entrée/de sortie différents" dans gitattributes[5].

Ce qu’il faut afficher entre ORIG_HEAD et le résultat de la fusion à la fin de la fusion, si cela existe. Les valeurs possibles sont :

Lorsque réglé sur true, créer automatiquement une entrée temporaire de remisage avant le début de l’opération, et l’appliquer après la fin de l’opération. Cela signifie que vous pouvez exécuter la fusion sur un arbre de travail sale. Cependant, à utiliser avec précaution : l’application finale du remisage après une fusion réussie peut entraîner des conflits non négligeables. Cette option peut être remplacée par les options --no-autostash et --autostash de git-merge[1]. La valeur par défaut est false.

Contrôle quel outil de fusion est utilisé par git-mergetool[1]. La liste ci-dessous indique les valeurs pré-intégrées valides. Toute autre valeur est traitée comme un outil de fusion personnalisé et nécessite qu’une variable mergetool.<outil>.cmd correspondante soit définie.

Contrôle quel outil de fusion est utilisé par git-mergetool[1] lorsque le drapeau -g/--gui est spécifié. La liste ci-dessous indique les valeurs pré-intégrées valides. Toute autre valeur est traitée comme un outil de fusion personnalisé et nécessite qu’une variable mergetool.<outilgraphique>.cmd correspondante soit définie.

Contrôle la quantité de production affichée par la stratégie de fusion récursive. Le niveau 0 ne produit rien, sauf un message d’erreur final si des conflits ont été détectés. Le niveau 1 ne produit que des conflits, le niveau 2 produit des conflits et des changements de fichiers. Les niveaux 5 et plus produisent des informations de débogage. La valeur par défaut est le niveau 2. Peut être écrasée par la variable d’environnement GIT_MERGE_VERBOSITY.

Définit un nom lisible par l’homme pour un pilote de fusion personnalisé de bas niveau. Voir gitattributes[5] pour plus de détails.

Définit la commande qui met en œuvre un pilote de fusion de bas niveau personnalisé. Voir gitattributes[5] pour plus de détails.

Nomme un pilote de fusion de bas niveau à utiliser lors d’une fusion interne entre des ancêtres communs. Voir gitattributes[5] pour plus de détails.