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.

Dis à git branch, git switch et git checkout`de créer des nouvelles branches de manière à ce que git-pull[1] fusionnera de manière appropriée depuis la branche de départ. Notez que même si cette option n'est pas définie, ce comportement peut être choisi branche par branche en utilisant les options `--track et --no-track. Cette option vaut par défaut true. Les paramètres valides sont :

Quand une nouvelle branche est créée avec git branch, git switch ou git checkout qui suit une autre branche, cette variable dit à Git de mettre en place le rebasage lors du tirage au lieu de la fusion (voir branch.<nom>.rebase). Les paramètres valides sont :

Cette variable contrôle l’ordre de tri des branches lorsqu’elles sont affichées par git-branch[1]. Sans l’option --sort=<valeur>, la valeur de cette variable comme valeur par défaut. Voir les noms de champs de git-for-each-ref[1] pour les valeurs valides.

Sur la branche <nom>, il dit à git fetch et git push quel distant duquel récupérer ou sur lequel pousser. Le distant sur lequel pousser peut être remplacée par remote.pushDefault (pour toutes les branches). Le distant sur lequel pousser, pour la branche actuelle, peut être encore surchargé par branch.<nom>.pushRemote. Si aucun distant n’est configurée, ou si vous n’êtes pas sur une branche et qu’il y a plus d’un distant défini dans le dépôt, il vaut par défaut origin pour la récupération et remote.pushDefault pour la poussée. En outre, . (un point) est le dépôt local actuel (un dépôt point), voir la dernière note de branch.<nom>.merge ci-dessous.

Quand la branche <nom> est extraite, surcharge branch.<nom>.remote pour pousser. Il remplace aussi remote.pushDefault pour pousser depuis la branche <nom>. Lorsque vous tirez d’un endroit (p. ex. votre amont) et poussez vers un autre endroit (p. ex. votre propre dépôt de publication), vous voudriez définir remote.pushDefault pour spécifier le distant où pousser pour toutes les branches, et utiliser cette option pour la surcharger pour une branche spécifique.

Définit, avec branch.<nom>.remote la branche amont de la branche donnée. Cela indique à git fetch/git pull/git rebase quelle branche fusionner et peut aussi affecter git push (voir push.default). Quand dans la branche <nom>, cela indique à git fetch le spéc de réf par défaut à marquer pour la fusion dans FETCH_HEAD. La valeur est manipulée comme la partie distante d’une spéc de réf, et doit correspondre à une réf qui est récupérée depuis un distant donné par branch.<nom>.remote. Les informations de fusion sont utilisées par git pull (qui appelle d’abord git fetch) pour rechercher la branche par défaut à fusionner. Sans cette option, git pull fusionne par défaut le premier spéc de réf récupéré. Spécifiez plusieurs valeurs pour obtenir une fusion octopus. Si vous souhaitez configurer git pull afin qu’il fusionne dans <nom> depuis une autre branche dans le dépôt local, vous pouvez pointer branch.<nom>.merge`sur la branche souhaitée, et utiliser le chemin relatif `. (un point) pour branch.<nom>.remote.

Définir les options par défaut pour la fusion dans la branche <nom>. La syntaxe et les options prises en charge sont les mêmes que celles de git-merge[1], mais les valeurs d’options contenant des espaces ne sont actuellement pas prises en charge.

Quand cela est vrai, rebaser la branche <nom> au sommet de la branche récupérée, au lieu de fusionner la branche par défaut depuis le distant par défaut quand git pull est exécuté. Voir pull.rebase pour ce faire d’une manière non spécifique à une branche.

Description de la branche, peut être modifiée avec git branch --edit-description. La description de la branche est automatiquement ajoutée à la lettre d’introduction de format-patch ou request-pull.

Quand vous lancez git checkout <quelquechose> ou git switch <quelquechose> et vous n’avez qu’un seul distant , la commande revenir implicitement à extraire et suivre, p.ex. origin/<quelquechose>. Cela cesse de fonctionner dès que vous avez plus d’un distant avec une référence <quelquechose>. Ce réglage permet de définir le nom d’un distant préféré qui devrait toujours gagner quand il s’agit de lever les ambiguïtés. Le cas d’utilisation typique est de définir ceci à origine.

Fournit la valeur par défaut pour l’option --guess ou --no-guess dans git checkout et git switch. Voir git-switch[1] et git-checkout[1].

Le nombre de travailleurs parallèles à utiliser lors de la mise à jour de l’arbre de travail. La valeur par défaut est un, soit une exécution séquentielle. Si la valeur est inférieure à un, Git utilisera autant de travailleurs que le nombre de cœurs logiques disponibles dans le microprocesseur. Ce réglage et ‘checkout.thresholdForParallelism’ affectent toutes les commandes qui effectuent une extraction, par exemple, checkout, clone, reset, sparse-checkout, etc.

Lors de l’exécution de l’extraction parallèle avec un petit nombre de fichiers, le coût de lancer des sous-processus et de la communication inter-processus pourrait dépasser les gains de parallélisation. Ce paramètre vous permet de définir le nombre minimum de fichiers pour lesquels la commande parallèle devrait être tentée. La valeur par défaut est 100.

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

Cette option contrôle si git fetch (et la récupération sous-jacente dans git pull) va se récupérer récursivement dans les sous-modules peuplés. Cette option peut être définie soit à une valeur booléenne, soit à on-demand. La régler à une valeur booléenne modifie le comportement de la récupération et de tirage pour aller récursivement dans les sous-modules quand elle est à true et à ne pas aller récursivement du tout si elle est à false. Lorsqu’elle est mise à on-demand, la récupération et le tirage ne seront traités récursivement dans un sous-module peuplé que lorsque son superprojet récupère un commit qui met à jour la référence du sous-module. Par défaut à on-demand ou à la valeur de submodule.recurse si elle est renseignée.

Si elle est définie à true, git-fetch-pack vérifiera tous les objets récupérés. Voir transfer.fsckObjects pour indiquer ce qui est vérifié. Par défaut à false. Si elle n’est pas définie, la valeur de `transfer.fsckObjects ' est utilisée à la place.

Agit comme fsck.<id-msg>, mais est utilisé par git-fetch-pack[1] au lieu de git-fsck[1]. Voir la documentation de fsck.<id-msg> pour les détails.

Agit comme fsck.skipList, mais est utilisé par git-fetch-pack[1] au lieu de git-fsck[1]. Voir la documentation de fsck.skipList pour les détails.

Si le nombre d’objets récupérés lors du transfert natif Git est inférieur à cette limite, les objets seront déballés dans des fichiers d’objets esseulés. Toutefois, si le nombre d’objets reçus est égal ou supérieur à cette limite, le paquet reçu sera stocké comme un fichier paquet, après avoir ajouté toute base delta manquante. Le stockage du paquet à partir d’une poussée peut rendre l’opération de poussée complète plus rapidement, surtout sur les systèmes de fichiers lents. Si elle n’est pas définie, la valeur de transfer.unpackLimit est utilisée à la place.

Si true, fetch se comportera automatiquement comme si l’option --prune était donnée sur la ligne de commande. Voir aussi remote.<nom>.prune et la section ÉLAGAGE de git-fetch[1].

Si la valeur est true, la récupération se comportera automatiquement comme si les spécs de réf refs/tags/*:refs/tags/* avaient été fournies lors de l’élagage, si ce n’était pas déjà réglé. Cela permet de configurer à la fois cette option et fetch.prune pour maintenir une cartographie de 1=1 avec les réfs en amont. Voir aussi remote.<nom>.pruneTags et la section ÉLAGAGE de git-fetch[1].

Si sa valeur est true, fetch tentera de mettre à jour tous les distants disponibles. Ce comportement peut être surchargé en passant --no-all ou en spécifiant explicitement un ou plusieurs distants à récupérer. Par défaut à false.

Contrôler comment le statut de mise à jour de ref est affiché. Les valeurs valides sont full et compact . La valeur par défaut est full. Voir la section SORTIE dans git-fetch[1] pour plus de détails.

Contrôler comment les informations sur les commits dans le dépôt local sont envoyées lors de la négociation du contenu du fichier paquet à envoyer par le serveur. Définir à consecutive pour utiliser un algorithme qui parcourt les commits consécutifs en vérifiant chacun. Réglez-la à skipping pour utiliser un algorithme qui saute les commits dans un effort pour converger plus rapidement, mais peut entraîner un paquet plus important que nécessaire ; ou réglez-la à noop pour ne pas envoyer d’informations du tout, ce qui entraînera presque certainement un paquet plus grand que nécessaire, mais sautera l’étape de négociation. Définissez-la à defaut pour surcharger les réglages faits précédemment et utiliser le comportement par défaut. La valeur par défaut est normalement consecutive, mais si feature.experimental est true, alors la valeur par défaut est skipping. Les valeurs inconnues causeront une erreur de git fetch.

Définissez-la à false pour activer --no-show-forced-updates dans les commandes git-fetch[1] et git-pull[1]. Par défaut à true.

Spécifie le nombre maximal d’opérations de récupération à exécuter en parallèle à un moment (submodules ou distants lorsque l’option --multiple de git-fetch[1] est en vigueur).

Réglez-le à true pour écrire un graphe de commit après chaque commande git fetch qui télécharge un fichier paquet depuis un distant. En utilisant l’option --split, la plupart des exécutions créeront un très petit fichier de graphe de commits sur le ou les fichiers de graphe de commits existants. Parfois, ces fichiers fusionnent et l’écriture peut prendre plus de temps. Ayant un fichier de graphe de commit mis à jour aide à la performance de nombreuses commandes Git, y compris git merge-base, git push -f, et git log --graph. Par défaut à false.

Cette valeur stocke une URI pour le téléchargement Git des données d’objets d’un URI groupé avant d’effectuer une récupération incrémentale depuis le serveur Git d’origine. Cela ressemble à la façon dont l’option --bundle-uri se comporte dans git-clone[1]. git clone --bundle-uri va régler la valeur de fetch.bundleURI si l’URI groupé qui est organisé pour les récupérations supplémentaires.

Lors de l’utilisation de fetch.bundleURI pour récupérer progressivement à partir d’une liste de colis qui utilise l’heuristique "creationToken", cette valeur de configuration stocke la valeur maximale creationToken des paquets téléchargés. Cette valeur est utilisée pour empêcher le téléchargement des colis dans le futur si la ‘creationToken’ annoncée n’est pas strictement plus grande que cette valeur.

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.

Si true , faire git-log[1], git-show[1], et git-whatchanged[1] assume --abbrev-commit. Vous pouvez surcharger cette option avec --no-abbrev-commit.

Régler le mode de date par défaut pour la commande log. Régler une valeur de log.date est similaire à l’utilisation de l’option --date de git log. Voir git-log[1] pour plus de détails.

Afficher les noms de réf de tous les commits qui sont montrés par la command log. Les valeurs possibles sont :

Par défaut, git log n’affiche que des décorations pour certains espaces de nom de réf connus. Si all est spécifié, alors afficher toutes les réfs comme décorations.

Exclure les motifs spécifiés des décorations de journal. Ceci est similaire à l’option de ligne de commande --decorate-refs-exclude, mais l’option de configuration peut être remplacée par l’option --decorate-refs.

Définir le format diff pour être utilisé lorsque --diff-merges=on est spécifié, voir --diff-merges dans git-log[1] pour les détails. Par défaut à separate.

Si true, git log agira comme si l’option --follow a été utilisée lorsqu’un seul <chemin> est fourni. Cela a les mêmes limites que --follow, c’est-à-dire que cela ne peut pas être utilisé pour suivre plusieurs fichiers et ne fonctionne pas bien sur un historique non linéaire.

Une liste de couleurs, séparées par des virgules, qui peut être utilisée pour dessiner des lignes d’historique dans git log --graph.

Si la valeur est true, le commit initial sera montré comme un grand événement de création. Ceci est équivalent à une diff contre un arbre vide. Des outils comme git-log[1] ou git-whatchanged[1], qui cachent normalement le commit racine, vont maintenant le montrer. true par défaut.

Si c’est true, git-log[1], git-show[1] et git-whatchanged[1] assument --show-signature.

Si la valeur est true, git-log[1], git-show[1] et git-whatchanged[1] assument --use-mailmap, sinon ils assument --no-use-mailmap. true par défaut.

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.

Surcharger le chemin pour l’outil donné. Ceci est utile si votre outil n’est pas dans le $PATH.

Spécifier la commande pour invoquer l’outil de fusion spécifié. La commande spécifiée est évaluée dans un shell avec les variables suivantes disponibles : BASE est le nom d’un fichier temporaire contenant la base commune des fichiers à fusionner, si disponible ; LOCAL est le nom d’un fichier temporaire contenant le contenu du fichier sur la branche actuelle ; REMOTE est le nom d’un fichier temporaire contenant le contenu du fichier de la branche à fusionner ; MERGED contient le nom du fichier dans lequel l’outil de fusion devra écrire le résultat d’une fusion réussie.

Permet à l’utilisateur de remplacer la valeur globale de mergetool.hideResolved pour un outil spécifique. Voir mergetool.hideResolved pour la description complète.

Pour une commande de fusion personnalisée, spécifier si le code de sortie de la commande de fusion peut être utilisé pour déterminer si la fusion a été réussie. Si cela n’est pas réglé à true alors l’horodatage du fichier cible de fusion est vérifié, et la fusion est supposée avoir été réussie si le fichier a été mis à jour ; sinon, l’utilisateur est invité à indiquer le succès de la fusion.

Les versions plus anciennes de meld ne gèrent pas l’option --output. Git tentera de déterminer si meld gère --output en inspectant la sortie de meld --help. Configurer mergetool.meld.hasOutput indiquera à Git de sauter ces vérifications et utilisera la valeur configurée à la place. Régler mergetool.meld.hasOutput à true indique à Git d’utiliser inconditionnellement l’option --output et false évite d’utiliser --output.

Lorsque l’option --auto-merge est donnée, meld fusionnera automatiquement toutes les parties non conflictuelles, mettra en évidence les parties en conflit et attendra la décision de l’utilisateur. Régler mergetool.meld.useAutoMerge à true indique à Git d’utiliser sans condition l’option --auto-merge avec meld. Régler cette valeur à auto permet de détecter si --auto-merge est pris en charge et n’utilisera que l’option --auto-merge lorsqu’elle est disponible. Une valeur à false évite complètement d’utiliser --auto-merge et c’est la valeur par défaut.

Configurer la configuration en fenêtre scindée pour la <variante> de vimdiff, parmi vimdiff, nvimdiff, gvimdiff. Lors du lancement de git mergetool avec --tool= <variante> (ou sans --tool si merge.tool est configuré comme <variante>), Git consultera mergetool. <variante>.layout pour déterminer la disposition de l’outil. Si la configuration spécifique à la variante n’est pas disponible, celle de vimdiff est utilisée par défaut. Si elle n’est pas non plus disponible, une mise en page par défaut avec 4 fenêtres sera utilisée. Pour configurer la mise en page, voir le INDICES SPÉCIFIQUES À UN BACKEND la section de git-mergetool[1].

Lors d’une fusion, Git résoudra automatiquement le plus de conflits possible et écrira le fichier $MERGED contenant des marqueurs de conflit autour de tout conflit qu’il ne peut résoudre ; $LOCAL et $REMOTE sont normalement les versions du fichier avant la résolution de conflit de Git. Ce drapeau provoque l’écrasement de $LOCAL et $REMOTE afin que seuls les conflits non résolus soient présentés à l’outil de fusion. Peut être configuré par outil via la variable de configuration mergetool.<outil>.hideResolved. Par défaut à false.

Après avoir effectué une fusion, le fichier original avec des marqueurs de conflit peut être enregistré comme fichier avec une extension .orig. Si cette variable est définie à false alors ce fichier n’est pas conservé. Par défaut à true (c.-à-d. garder les fichiers de sauvegarde).

Lorsque vous invoquez un outil de fusion personnalisé, Git utilise un ensemble de fichiers temporaires qu’il passe à l’outil. Si l’outil retourne une erreur et que cette variable est définie à true, alors ces fichiers temporaires seront conservés ; sinon, ils seront supprimés après la sortie de l’outil. Par défaut à false.

Git écrit des versions temporaires BASE, LOCAL et REMOTE des fichiers ayant des conflits dans l’arbre de travail par défaut. Git tentera d’utiliser un répertoire temporaire pour ces fichiers lorsque défini à true. Par défaut à false.

Demander avant chaque invocation du programme de résolution de fusion.

Définir à true pour utiliser merge.guitool par défaut (équivalant à spécifier l’argument --gui), ou auto pour sélectionner merge.guitool ou merge.tool selon la présence d`une valeur variable d’environnement DISPLAY. La valeur par défaut est false, où l`argument --gui doit être fourni explicitement pour que le merge.guitool soit utilisé.

Quelle stratégie de fusion choisir par défaut lors de la résolution des conflits de notes. Doit être au choix manual, ours, theirs, union, ou cat_sort_uniq . Par défaut à manual. Voir la section « STRATÉGIES DE FUSION DE NOTES » de git-notes[1] pour plus d’informations sur chaque stratégie.

La stratégie de fusion à choisir lors de la fusion denote dans refs/notes/ <nom>. Cela remplace le plus général notes.mergeStrategy. Voir la section « STRATÉGIES DE FUSION DE NITES » dans git-notes[1] pour plus d’informations sur les stratégies disponibles.

Depuis quelle réf (ou réfs, si un glob ou si spécifié plus d’une fois), en plus de la configuration réglée par défaut par core.notesRef ou GIT_NOTES_REF , lire les notes lors de l'affichage des messages de validation avec la famille de commandes git log.

Lors de la réécriture des commits avec <commande> (actuellement amend ou rebase), si cette variable est false, git ne copiera pas les notes de l’original vers le commit réécrit. Par défaut à true. Voir aussi notes.rewriteRef ci-dessous.

Lors de la copie de notes pendant une réécriture (voir l’option notes.rewrite.<commande>), détermine l’action à faire si le commit cible a déjà une note. Doit être parmi overwrite, concatenate, cat_sort_uniq, ou ignore. Par défaut à concatenate.

Lors de la copie des notes pendant une réécriture, spécifie la réf (totalement qualifiée) dont les notes doivent être copiées. Peut être un glob, auquel cas les notes dans toutes les réfs correspondantes seront copiées. Vous pouvez également spécifier cette configuration plusieurs fois.

Si c’est réglé à true, suppose --set-upstream sur une poussée par défaut lorsqu’il n’existe pas de suivi en amont pour la branche actuelle ; cette option prend effet avec les options de push.default, simple, upstream, et current. Il est utile si par défaut vous voulez que les nouvelles branches soient poussées vers le distant par défaut (comme le comportement de push.default=current) et vous voulez également que le suivi en amont soit défini. Les flux de travail les plus susceptibles de bénéficier de cette option sont des flux de travail centraux simple où toutes les branches devraient avoir le même nom sur le distant.

Définit l’action que git push devrait prendre si aucun refspec n’est donné (que ce soit depuis la ligne de commande, depuis la configuration ou d’ailleurs). Différentes valeurs sont bien adaptées pour des flux de travail spécifiques ; par exemple, dans un flux de travail purement central (c.-à-d. la source de récupération est égale à la destination de poussée), upstream est probablement ce que vous voulez. Les valeurs possibles sont :

Si défini à true, activer l’option --follow-tags par défaut. Vous pouvez remplacer cette configuration au moment de la poussée en spécifiant --no-follow-tags.

Peut être fixé à une valeur booléenne, ou la chaîne if-asked. Une valeur true provoque la signature GPG de toutes les poussées, comme si --signed était passé à git-push[1]. La chaîne if-asked provoque la signature des poussées si le serveur les gère, comme si --signed=if-asked était passé à git push. Une valeur false peut remplacer une valeur depuis un fichier de configuration de priorité inférieure. Un drapeau de ligne de commande explicite remplace toujours cette option de configuration.

Quand aucun argument --push-option=<option> n’est donné en ligne de commande, git push se comporte comme si chaque <option> de cette variable était donné comme --push-option=<option>.

Exemple :

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

Cela ne résultera qu'en b (a et c sont effacés).

Peut être check, on-demand, only, ou no, avec le même comportement que celui de push --recurse-submodules. Si ce n’est pas défini, no est utilisé par défaut, sauf si submodule.recurse est fixé (auquel cas une valeur true signifie on-demand ).

Si c’est fixé à true, cela équivaut à spécifier --force-if-includes comme option à git-push[1] sur la ligne de commande. Ajouter --no-force-if-includes au moment de pousser surcharge ce réglage de configuration.

Si c’est réglé à true, essayer de réduire la taille du fichier paquet envoyé par des rondes de négociation dans lesquelles le client et le serveur tentent de trouver des commits en commun. Si false, Git s’appuiera uniquement sur l’annonce des réfs du serveur pour trouver des commits en commun.

Si c’est réglé à false , désactiver l’utilisation de bitmaps pour git push même si pack.useBitmaps est true , sans empêcher d’autres opérations de git d’utiliser des bitmaps. La valeur par défaut est true.

Le backend par défaut à utiliser pour le rebasage. Les choix possibles sont apply ou merge. À l’avenir, si le backend de fusion gagne toutes les capacités restantes du backend, ce paramètre peut devenir inutilisé.

S’il faut afficher un diffstat de ce qui a changé en amont depuis le dernier rebasage. Par défaut à false.

Si réglé à true, activer l’option --autosquash de git-rebase[1] par défaut pour le mode interactif. Cela peut être surchargé par l’option --no-autosquash.

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 rebaser sur un arbre de travail sale. Cependant, à utiliser avec précaution : l’application finale du remisage après un rebasage peut entraîner des conflits non négligeables. Cette option peut être remplacée par les options --no-autostash et --autostash de git-rebase[1]. La valeur par défaut est false.

Si défini à true, active l’option --update-refs par défaut.

Si réglé à "warn", git rebase -i affichera un avertissement si certains commits sont supprimés (par exemple une ligne a été supprimée), cependant le rebasage va continuer. S’il est défini à "error", il affichera l’avertissement précédent et arrêtera le rebasage, git rebase --edit-todo peut ensuite être utilisé pour corriger l’erreur. S’il est défini à "ignore", aucun contrôle n’est fait. Pour abandonner un commit sans avertissement ni erreur, utilisez la commande drop dans la liste de todo. Par défaut à "ignore".

Une chaîne de format, comme spécifié dans git-log[1], à utiliser pour la liste de todo lors d’un rebasage interactif. Le format aura automatiquement l’empreinte de commit préfixé au format.

Si réglé à true, git rebase utilisera des noms de commande abrégés dans la liste de todo qui en résultent :

	p deadbee Le titre de ce commit
p fa1afe1 Le titre du commit suivant
...

	pick deadbee Le titre de ce commit
	pick fa1afe1 Le titre du commit suivant
	...

Reprogrammer automatiquement les commandes exec qui ont échoué. Cela n’a de sens qu’en mode interactif (ou lorsqu’une option --exec a été fournie). C’est la même chose que de spécifier l’option --reschedule-failed-exec.

Si défini à false, régler l’option --no-fork-point par défaut.

Si et comment définir l’option --rebase-merges par défaut. Peut être rebase-cousins, non-rebase-cousins, ou un booléen. La régler à true ou à no-rebase-cousins est équivalent à --rebase-merges=no-rebase-cousins, la régler à rebase-cousins est équivalent à --rebase-merges=rebase-cousins, et la régler à false est équivalent à --no-rebase-merges. Passer --rebase-merges sur la ligne de commande, avec ou sans argument, annule toute configuration rebase.rebaseMerges.

Lors de la génération de noms à partir de sujets de commit, tronquer les noms à cette longueur. Par défaut, les noms sont tronqués à un peu moins que NAME_MAX (pour permettre par exemple d’écrire des fichiers .lock pour les réfs esseulées correspondantes).

Éditeur de texte utilisé par git rebase -i pour modifier le fichier d’instruction de rebase. La valeur est censée être interprétée par le shell lorsqu’elle est utilisée. Il peut être remplacé par la variable d ' environnement GIT_SEQUENCE_EDITOR . Lorsqu’il n’est pas configuré, l’éditeur de message par défaut est utilisé à la place.

Si la valeur est true, git stash apply et git stash pop se comportera comme si --index était fourni. Par défaut à false. Voir les descriptions dans git-stash[1].

Si c’est réglé à true, la commande git stash show montrera les fichiers non suivis d’une entrée de remisage. Vaut par défaut false. See the description of the 'show' command in git-stash[1].

Si cela est vrai, la commande git stash show sans option affichera l’entrée de remisage sous forme de rustine. Par défaut à faux. See the description of the 'show' command in git-stash[1].

Si cela est à true, la commande git stash show sans option affichera un diffstat de l`entrée de remisage. Par défaut à true. See the description of the 'show' command in git-stash[1].

Un booléen pour spécifier si les étiquettes annotées créées doivent être signées avec GPG. Si l’option --annotate est spécifiée sur la ligne de commande, elle a priorité sur cette option.

Cette variable contrôle l’ordre de tri des étiquettes lorsqu’elles sont affichées par git-tag[1]. Sans l 'option --sort=<valeur>, la valeur de cette variable sera utilisée comme valeur par défaut.

Un booléen pour spécifier si toutes les étiquettes doivent être signés par GPG. L’utilisation de cette option lors du lancement d’un script automatique peut entraîner un grand nombre de signature d’étiquettes. Il est donc pratique d’utiliser un agent pour éviter de taper votre mot de passe GPG plusieurs fois. Notez que cette option n’affecte pas le comportement de signature des étiquettes activé par les options -u<id-clé> ou --local-user=<clé-id>.

Si aucune branche n’est spécifiée et que -b ni -B ni --detach ne sont utilisés, alors git worktree add revient par défaut à la création d’une branche depuis HEAD. Si worktree.guessRemote est fixé à true, worktree add tente de trouver une branche de suivi à distance dont le nom correspond uniquement au nouveau nom de branche. Si une telle branche existe, elle est extraite et définie comme « amont» pour la nouvelle branche. Si aucune telle correspondance n’est trouvée, elle revient à créer une nouvelle branche de la HEAD actuelle.

Lier les arbres de travail utilisant des chemins relatifs ( si "true") or absolus (si "false"). Ceci est particulièrement utile pour les configurations où le dépôt et les arbres de travail peuvent être déplacés entre différents emplacements ou environnements. Par défaut à "false".