178 votes

Coloration des espaces blancs dans la sortie de git-diff

En ce qui concerne le formatage du code, je suis un peu puriste :). Je supprime très souvent les espaces blancs inutiles (lignes avec seulement des ws, ws à la fin des lignes etc). J'ai même configuré vim pour qu'il affiche ce genre de lignes en rouge.

Mon problème est qu'en utilisant git-diff, je vois souvent quelque chose comme ceci :

-      else{ 
+      else{

Même si j'ai coloré git-diff, je ne peux pas voir la différence (dans cette situation particulière, j'ai supprimé 1 ws en fin de ligne). Existe-t-il un moyen de dire à git-diff de montrer les ws colorés en rouge (par exemple ceux qui correspondent à / \s +$/ regexp).

5 votes

Si vous inversez les couleurs (en intervertissant l'avant-plan et l'arrière-plan), les changements d'espace blanc comme celui-ci apparaîtront. Un moyen facile d'y parvenir dans de nombreux terminaux consiste à mettre en surbrillance le texte en question avec la souris. Cette astuce ne fonctionne qu'avec un diff coloré, bien sûr.

195voto

Mark Longair Points 93104

Avec avec Git 2.11 (Q4 2016) et après, vous pouvez le faire :

git config diff.wsErrorHighlight all

Voir doc sur git diff y sur git config .


Pour les versions antérieures à celle-ci, vous pouvez définir l'option color.diff.whitespace configuration, par exemple avec :

git config color.diff.whitespace "red reverse"

(Je suppose que vous avez déjà color.diff o color.ui réglé sur auto puisque vous dites que vous voyez des taches colorées à partir de git diff de toute façon.)

Si vous souhaitez affiner le type d'erreurs d'espacement qui sont mises en évidence en rouge, vous pouvez alors modifier les paramètres suivants core.whitespace mais blank-at-eol est activé par défaut, vous n'aurez donc probablement pas besoin de le modifier pour l'exemple que vous mentionnez.

Une source possible de confusion est que dans la sortie de git diff les erreurs d'espacement ne sont mises en évidence que dans les lignes qui sont introduites, et non dans celles qui sont supprimées. ( Mise à jour : comme le souligne Paul Whittaker dans sa réponse que vous devriez voter :), vous pouvez les voir en inversant le sens de la différence avec git diff -R .)

Vous pouvez trouver plus de documentation sur ces options de configuration dans le manuel de l'utilisateur. Page de manuel git config

Si vous ne voulez pas utiliser le -R vous pouvez utiliser l'option Mise en évidence de l'erreur WhiteSpace de l'option page de manuel diff .

--ws-error-highlight= (mise en évidence des erreurs)

Met en évidence les erreurs d'espacement sur les lignes spécifiées par dans la couleur spécifiée par color.diff.whitespace. est une liste séparée par des virgules de l'ancien, du nouveau et du contexte. Lorsque cette option n'est pas donnée, seules les erreurs d'espacement dans les nouvelles lignes sont mises en évidence. Par exemple --ws-error-highlight=new,old met en évidence les erreurs d'espacement sur les lignes supprimées et ajoutées. all peut être utilisé comme raccourci pour old,new,context.

git diff --ws-error-highlight=new,old <file>

o

git diff --ws-error-highlight=all <file>

Avec les versions antérieures à la 2.11, il n'y a aucun moyen d'activer cette fonction de façon permanente et de la stocker dans la configuration, à part l'utilisation d'un alias :

git config alias.df 'diff --ws-error-highlight=all'

Maintenant, vous pouvez utiliser :

git df <file>

Pour voir les changements en rouge.

34 votes

"Une source possible de confusion est que dans la sortie de git diff, les erreurs d'espacement ne sont mises en évidence que dans les lignes qui sont introduites, pas celles qui sont supprimées." Exactement ! Et il n'y a aucun moyen de le montrer aussi pour les lignes supprimées ? (hé, c'est diff :))

1 votes

Pas à ce que je sache, mais je pourrais très bien avoir manqué quelque chose. Je suppose que la logique est la suivante : puisque vous supprimez ces lignes, qui se soucie de savoir si elles ont des erreurs d'espacement ou non ?)

6 votes

Ajoutez --global pour définir dans votre ~/.gitconfig

155voto

Paul Whittaker Points 922

Utilisez git diff -R pour transformer les lignes supprimées en lignes ajoutées. Les espaces blancs de fin de ligne seront alors mis en évidence.

(Cela suppose que vous avez déjà activé l'éclairage de l'espace blanc, conformément aux paramètres de couleur de la réponse de Mark. Le mérite de cette méthode revient au post de Junio à l'adresse suivante http://git.661346.n2.nabble.com/Highlighting-whitespace-on-removal-with-git-diff-td5653205.html .)

Par exemple, lors de la conversion d'un fichier avec des terminaisons de ligne DOS en Unix, git diff -R me montre clairement la ^M les caractères (dés)apparaissant en fin de ligne. Sans -R (et aussi sans -w etc.) il montre que le fichier entier a été modifié, mais ne montre pas comment.

4 votes

Bien sûr, vous pouvez aussi faire git diff | cat -A | less -S si vous êtes désespéré, mais en plus des retours chariot, les cat affichera également les codes d'échappement de mise en évidence des couleurs, littéralement.

3 votes

@Paul_Whittaker cat -A n'est pas portable. Sur BSD cat, cette option n'existe pas. Veuillez utiliser cat -vet à la place.

10voto

Kelvin Points 5810

Utilisez git diff --color | less -R . Le site -R rend les codes de contrôle de couleur conviviaux.

Vous pouvez alors utiliser less La recherche par expressions régulières de l'utilisateur, par exemple

/[[:space:]]+$

0 votes

Cette expression régulière fonctionne également sur vim d'ailleurs.

0 votes

Cette dernière idée de less -R a juste rendu plus facile pour moi de pipe ls --color par le biais de less .

9voto

user1338062 Points 1553

Pour les écumeurs de réponses paresseux, il suffit de courir :

git config --global diff.wsErrorHighlight all

Puis git diff mettra également en évidence les espaces de fin de ligne dans les lignes supprimées.

0voto

nickgrim Points 2672

Ma version de git diff semble déjà faire cela - j'ai git 1.7.4.1 et j'ai configuré color.ui = auto .

12 votes

Je viens de tester avec git 1.7.5.1 et il ne met certainement pas en évidence les espaces blancs de fin de ligne dans les lignes à supprimer.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X