je visite git, en suivant diverses pages du web, et j’ai lancé les commandes suivantes, conseillées ici:
/www.siteduzero.com/tutoriel-3-254198-gerez-vos-codes-source-avec-git.html#ss_part_2
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
Je suppose qu’il y a un rapport entre ce problème et ces commandes, mais je ne trouve pas comment les neutraliser.
Il y a aussi dans ~/.gitconfig les lignes suivantes, qui y sont probablement d’origine ( paquet deb de squeeze )
Les signes bizarres que tu vois sont des codes couleurs, ton terminal ne les supporte apparemment pas.
Désactive les options color.* dans ton .gitconfig ou bien tente de configurer ton terminal si c’est possible.
J’utilise (u)xterm en mode 256 couleurs et je n’ai aucun problème à signaler avec les couleurs de git.
pourquoi de très nombreuses commandes n’ont pas de problème avec la couleur et git en pose un ? mystère. Il est écrit dans la doc que git est configuré par défaut en utf8, ce qui est le cas de mon environnement habituel, que je viens de vérifier onglet par onglet.( terminal gnome 2.30.2 )
extrait de git show --help
[quote] --encoding[=]
The commit objects record the encoding used for the log message in their encoding header; this option can be used to tell the command to re-code the commit log message in the encoding preferred by the user. For non plumbing commands this defaults to UTF-8.[/quote]
J’essaierai donc (plus tard) d’introduire encoding dans .gitconf, en remettant les directives couleurs, et vous ferai part de mes conclusions.
Les couleurs dans le terminal c’est un peu du vaudou des fois (mais ce n’est pas lié à l’UTF-8), il peut y avoir des interférences entre le terminal et le shell ou des variables d’environnement mal positionnées (comme TERM).
Sur le site de Gnome (live.gnome.org/Git/Developers) ils conseillent d’ajouter “export LESS=-R” dans le .bashrc en cas de problème.
C’est peut être une solution pour toi ?