(basé sur Git 1.8.1.2 ; certains réglages peuvent ne pas être disponibles sur de plus anciennes versions)

J'ai volontairement laissé de côté les aspects rerere, qui sont plus du domaine de la conf locale… Quelques explications sur les réglages (git help config pour la totale) :

• user.name et user.email sont indispensables à une bonne identification de l'auteur de vos commits.
• color.ui règle de façon générale les exploitations de la couleur pour les différents contextes (diff, branch, interactive, etc.). auto indique qu'on y aura recours si le contexte (terminal, pipes, etc.) le gère.
• alias.*sont mes aliases indispensables. La complétion pourstatusexige de saisirstatà cause des commandes proches, etciest un raccourci ultra-fréquent pourcommit, qui exige lui 3 caractères pour lever l'ambiguïté à la base.lg` est mon log "graphique" sur-mesure, mais disponible en mode texte dans un shell. Je n'ai jamais recours aux visualiseurs de logs graphiques, du coup…
• core.pager est exploité pour tout affichage plus long que la hauteur de terminal. Je préfère paginer explicitement, donc en indiquant cat je ne pagine plus par défaut
• core.editor gouverne l'éditeur employé par Git. À défaut, celui défini par le système (variable d'environnement EDITOR, etc.) sera employé. J'utilise SublimeText moi-même avec son wrapper subl installé dans mon PATH, donc j'emploie subl -w comme valeur.
• diff.mnemonicPrefix permet à diff, au lieu de préfixer les fichiers comparés par a/ et b/, d'utiliser comme lettres c (commit), i (index, c'est-à-dire stage) et w (working directory), ce qui est parfois utile pour y voir clair…
• diff.wordRegex est la regex employée par défaut par git diff --word-diff. En la réglant à . je réduis la détection de diff au plus court contenu possible, ce qui m'évite d'avoir à le faire manuellement avec git diff --word-diff-regex=..
• fetch.recurseSubmodules détecte automatiquement lors d'un fetch/pull si les références des submodules ont bougé, et propose de les récupérer automatiquement si c'est le cas. Attention, ça ne fait pas le submodule update pour autant.
• grep.extendedRegexp me permet d'employer des regexp étendues (caractères du genre (, +, etc.) sans avoir à préciser -E dans ma ligne de commande
• log.abbrevCommit s'assure que tous mes appels à git log afficheront les commits au format abrégé.
• merge.conflictStyle me permet de bénéficier du format diff3 sur mes conflits au sein des fichiers ; ce format affiche non seulement les versions locale et distante (ou récipiendaire et source, si vous préférez), mais aussi la version de l'ancêtre commun.
• mergetool.keepBackup et mergetool.keepTemporaries s'assurent que mes outils de fusion, quels qu'ils soient, ne laissent pas traîner des fichiers artefacts après leur exécution (vous savez, du genre truc.orig et truc.rej en traitant le fichier truc).
• mergetool.prompt m'évite d'avoir à confirmer avec Entrée lorsque je fais un git mergetool (ou un git difftool, soit dit en passant).
• pull.rebase garantit que tous mes pulls feront un rebase plutôt qu'un merge. J'expliquerai en détail pourquoi je préfère ça dans un futur billet Git Attitude, mais en 3 mots : propreté de l'historique.
• push.default m'évite de me faire gronder par git push, sous prétexte que j'ai encore une branche locale trackée dans un coin dont je ne m'occupe plus et qui est en retard sur le remote, lorsque je pushe depuis une autre.
• status.submoduleSummary prend soin de signaler les submodules dont la référence a bougé dans git status, en listant les deltas de commits concernés.

Il y a une option qui n'est pas commentée, c'est git.core.whitespace

Si j'en crois la doc c'est pour désactiver l'auto suppression des espaces en fin de ligne. C'est ça ?

Bonjour Charles,

(désolé pour le lag, je n'avais apparemment pas été notifié par e-mail de ton commentaire)

Pas exactement… Git ne retire pas ces trucs-là pour toi via cette option : il faudrait un filtre textuel. C'est généralement plutôt le boulot, en amont, de ton éditeur (tous les éditeurs valables savent le faire).

L'option core.whitespace liste les « problèmes » d'espacement à considérer/signaler lors d'un git diff (et par extension un git add -p) ou d'un git apply --whitespace=errors, et à tenter de corriger lors d'un git apply ou git rebase en --whitespace=fix.

La valeur trailing-space est un raccourci pour blank-at-eol,blank-at-eof, qui cible donc les espacements en fin de ligne et les lignes en fin de fichier (ce dernier souci est très courant). Indiquée ici en négatif (-trailing-space), elle désactive ces détections / ne considère pas ces aspects comme problématiques.

Un grand merci pour la config

Just added the %ad variant in git lg, defaulting to --date=relative, to let you override the date format in git lg using --date=…. Neat trick by Erwann Leblanc 🎉

Merci pour ces précieuses informations !
L'option pull.rebase est presque géniale ; elle ne me montre plus ce que je pull, y a t il moyen de revoir tout ça ?
Merci

Heeeeu en fait pull.rebase ne change rien au fonctionnement du fetch, c'est après que ça change (rebase au lieu de merge). Du coup si tu ne vois rien avant la partie rebase, c'est qu'en fait tu étais, sur ton essai, à jour côté fetch.

Dernière mise à jour à l'instant, suite aux suggestions de @mbrehin

@tdd les suggestions de @mbrehin sont visibles quelque part ? (Pour comprendre les différences)

@tdd les suggestions de @mbrehin sont visibles quelque part ? (Pour comprendre les différences)

Autant pour moi, j’avais suivi un lien ou j’avais pas l’historique du Gist.

@tdd Un avis sur l'utilisation de pager = less -FX comme proposé ici ?

@bgondy on utilise diff-so-fancy même si ça n’est pas retranscrit ici (on ne veut pas forcer la main et imposer un outil externe aux gens qui souhaitent récupérer cette conf).

En pratique notre conf contient ça : pager = diff-so-fancy | less --tabs=4 -RFX