In Git 2.9, you can now ask it to filter the diffs [interactive staging] shows through any script you like:

$ git config interactive.diffFilter diff-highlight

Ever got annoyed how you get "root" as author in your etckeeper commits made through sudo? I do. The problem does not exist with etckeeper commit, but the etckeeper interface doesn't allow for committing only a subset of the changes (which is one of many Git super-useful features). So I want to use git commit. But it records myself as root.

The problem is that sudo makes us essentially root. One could argue that well, it's the point! Indeed it is, though here we want to get root's rights, yet still be ourselves. There are various possible solutions to this, and here are some:

1) use sudo -E. This tells sudo not to reset any of the environment variables, which keeps among other things $HOME, in which Git will find your .gitconfig. This is easy, but it's a nuclear option with a nuclear cloud coming back your way: you lose all security advantages of sudo's environment cleanup.

2) if you're the only one on the machine, you can set user.name and user.email in the /etc repository. But if you're gonna do this, it's arguable how useful it is to know who committed, as it'll still always be the same person, just not root.

3) manually pass --author to git commit. This is annoying, though.

4) set GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL/GIT_COMMITTER_NAME/GIT_COMMITTER_EMAIL variables in your environment (.profile, .bashrc, wherever you get them the way you want), and list them in sudo's env_keep configuration setting. This mostly just Does What You Want™ -- but beware! these environment variables take precedence over Git's configuration, so it will apply whenever you use Git, not only in /etc, and regardless of your user.name and user.email settings.

You can pick whichever solution you like the best (or find another one). A clever user could even write a script or shell function to wrap the git call to set the author info when appropriate (either a full wrapper being "smart", or a special named one for use when committing in /etc).

Bonus, because I'm so kind, here's a script that picks the values from the .gitconfig of the user that called sudo, and runs git with whichever argument you gave it:

#!/bin/sh

# set to the git executable
GIT=git

# if running under sudo, try and use the caller's git config
if [ -n "$SUDO_USER" ]; then
  if [ -z "$GIT_CONFIG" ]; then
    sudo_user_home=$(getent passwd "$SUDO_USER" | cut -d: -f6)
    [ -n "$sudo_user_home" ] && GIT_CONFIG="$sudo_user_home/.gitconfig"
  fi
  [ -n "$GIT_CONFIG" -a -f "$GIT_CONFIG" ] && export GIT_CONFIG

  [ -z "$GIT_AUTHOR_NAME" ] && GIT_AUTHOR_NAME=$("$GIT" config user.name)
  [ -z "$GIT_AUTHOR_EMAIL" ] && GIT_AUTHOR_EMAIL=$("$GIT" config user.email)

  [ -n "$GIT_AUTHOR_NAME" ] && export GIT_AUTHOR_NAME
  [ -n "$GIT_AUTHOR_EMAIL" ] && export GIT_AUTHOR_EMAIL
fi

exec "$GIT" "$@"

Can be put in e.g. /usr/local/sbin/etcgit or something similar and called instead of git. Or it could be used as a drop-in replacement for git itself (just set GIT to the absolute path to the real git so the script doesn't call itself recursively).

Of course, the script has to be in the PATH sudo uses (~/bin is not).

Avec l'option -x de less, il est possible de définir la position des fins de tabulations (tab stops). C'est fort pratique pour visualiser un fichier qui utilise des tabulations d'une largeur différente de 8 (la valeur par défaut), avec par exemple less -x4.

Encore mieux, il est possible de spécifier plusieurs positions, ce qui est très utile par exemple pour visualiser un diff d'un fichier contenant des tabulations : en effet, comme chaque ligne d'un diff contient un caractère de contrôle en plus (+, - ou espace), les tabulations peuvent ne plus être alignées (si par exemple une tabulation de 8 commençait à l'offset 7, elle commencera alors à l'offset 8… et terminera alors à 16).
Et donc pour ce cas, il suffit de définir une première largeur de 9 (8 + le caractère de contrôle de diff), puis une de 8 : less -x9,17.

Et bien sûr c'est fort pratique pour Git : si la majeure partie des sorties de Git qui contiennent des tabulations que vous consultez sont des diffs (ce qui est fort probable), définir core.pager à less -x9,17 (ou autre valeur appropriée à votre projet) permet d'avoir des tabulations bien alignées sans avoir à définir PAGER à la main pour chaque appel.
À noter bien sûr que cette propriété de configuration peut être aussi bien définie dans votre ~/.gitconfig global que le .git/config d'un dépôt particulier (très pratique si un projet particulier utilise un largeur de tabulation différente de 8).

Après vous être pris la tête pendant un bon moment à voir « le patch ne s'applique pas », vous vous rendrez compte que git am supprime les CR par défaut.

J'imagine que le but est de simplifier la vie des gens qui reçoivent des patchs par email (puisque la fin de ligne pour les mails est CR-LF) et que la plupart des fichiers utilisent seulement LF.
Moins pratique par contre si l'on a utilisé git format-patch et qu'un des fichiers avait des CR-LF.

Solution : passer l'option --keep-cr à git-am.

Je savais qu'on pouvait tout faire, mais bowdel !
Lire aussi la section suivante pour les plages : http://git-scm.com/docs/git-rev-parse#_specifying_ranges

hg n'a pas directement le format-patch de Git, qui est très pratique non seulement pour envoyer des patches par mail (où hg a l'extension Patchbomb), mais aussi pour simplement exporter vers un fichier par exemple pour attacher à un rapport de bug.

hg a export qui fait le boulot, mais qui n'écrit pas automatiquement dans un fichier. Pour ce faire, il faut utiliser -o (--output), et écrire un nom de fichier à la main. Heureusement on peut utiliser des des formats automatisés comme %n et %m. Pour une sortie similaire à format-patch on utilisera -o '%n-%m.patch'.

Comme tout ça est bien verbeux, je suggère un alias (http://www.selenic.com/mercurial/hgrc.5.html#alias) :

[alias]
format-patch = export -v -o '%n-%m.patch'

Les branches sous Git sont réputées pour êtres différentes de celles des autres systèmes, et c'est vrai. La fonctionnalité de hg la plus proche de celle des branches Git sont les bookmarks.
Pas évident de prime abord, mais ça marche plutôt bien (au moins pour un utilisateur occasionnel venant de Git).

Le comportement par défaut du log de hg est proprement exaspérant pour un utilisateur de Git : la révision par défaut étant tip:0 (qui n'est pas nécessairement l'état courant).
Pour avoir le log de l'état courant du dépôt, comme le fait Git par défaut : -f (--folow). On ajoutera -v pour avoir des messages complets.
Pour inclure les différences on utilisera p, comme avec Git (peut-être en combinaison avec -g pour avoir le format étendu de Git, même s'il ne change rien pour les diffs les plus courants).

Un autre must-have, le pendant du color de Git, et fonctionne à peu près pareil.

Must-have, particulièrement pour tout utilisateur de Git qui a l'habitude d'un comportement pratique par défaut. Comme son nom l'indique, cette extension permet d'utiliser un pager automatiquement sur la sortie de la plupart des commandes, comme par exemple log ou export.

Les options suggérées pour less sont très bonnes, et fonctionnent comme Git :
F : quitter less automatiquement si la sortie tient sur l'écran
R : garder les séquences d'échappement pour la coloration (utile en particulier avec l'extension color)
X : ne pas vider la vue à la sortie, indispensable quand on utilise F