# git blame -w pour ignorer le bruit des changements d’indentation d’un fichier > L'option -w de git blame ignore les différences d'espaces et d'indentation lors de l'attribution de chaque ligne, pour remonter au véritable auteur d'un changement plutôt qu'à celui d'un simple reformatage automatique. - Auteur : WordPress Développement - Publié le : 2026-10-11 - Mis à jour le : 2026-09-30 - Catégorie : Outils & workflow - URL : https://www.wpmoderne.fr/outils/git-blame-w-ignorer-indentation/ ## L’essentiel - git blame -w ignore les espaces lors de la comparaison ligne à ligne - Sans elle, un reformatage automatique masque l'auteur réel du contenu - L'option se combine avec -C et -M pour suivre le code déplacé ou copié Un commit de reformatage automatique, exécuté un jour sur l'ensemble d'un thème pour aligner l'indentation sur un standard de codage, laisse une trace durable et gênante dans l'historique : chaque ligne touchée, même une seule fois pour ajouter deux espaces, se retrouve attribuée à ce commit de reformatage par `git blame`, masquant le nom du développeur qui a réellement écrit le contenu. L'option `-w`, ajoutée à `git blame`, corrige précisément ce problème. ## Ce que fait -w concrètement Par défaut, `git blame` compare le contenu de chaque ligne entre deux versions successives d'un fichier de manière stricte : si l'indentation change, même sans qu'un seul caractère de code ne soit modifié, la ligne est considérée comme différente et attribuée au commit qui a introduit ce changement. L'option `-w` (pour *ignore whitespace*, littéralement « ignorer les espaces ») demande à Git de comparer le contenu des lignes en ignorant les différences d'espaces et de tabulations lors de la détection de changement : ``` git blame -w includes/class-catalogue-produits.php ^a1f3c9e (Claire Dubois 2022-03-14 10:12 42) if ( ! empty( $produits ) ) { 7b2e410f (Marc Lenoir 2022-08-02 16:40 43) foreach ( $produits as $produit ) { 7b2e410f (Marc Lenoir 2022-08-02 16:40 44) echo esc_html( $produit->titre ); ``` Sans `-w`, ces mêmes lignes, si elles ont subi un passage de réindentation automatique postérieur, afficheraient le hash et la date du commit de reformatage plutôt que ceux de Claire Dubois et Marc Lenoir, les auteurs réels du contenu logique. L'option ne change rien à l'affichage du fichier lui-même : elle change uniquement la manière dont Git décide, en interne, si une ligne a « vraiment » changé d'un commit à l'autre. ## Le scénario typique : un passage global de mise en forme > L'essentiel à retenir : git blame -w ignore les espaces lors de la comparaison ligne à ligne ; Sans elle, un reformatage automatique masque l'auteur réel du contenu ; L'option se combine avec -C et -M pour suivre le code déplacé ou copié Ce cas se présente très concrètement dès qu'un projet adopte tardivement un standard de codage, comme les règles de PHP_CodeSniffer alignées sur les conventions WordPress, et qu'un développeur exécute un correctif automatique sur l'ensemble du dépôt en une seule fois. Ce commit, souvent volumineux et légitime, remplace des tabulations par des espaces ou inversement, aligne des accolades, ou uniformise l'indentation de blocs conditionnels imbriqués. Techniquement correct et utile au projet, il devient ensuite un obstacle systématique à toute tentative de retrouver, ligne par ligne, qui a réellement écrit chaque portion de logique. Sans l'option `-w`, un développeur qui cherche à comprendre pourquoi une condition particulière a été écrite ainsi se retrouve à consulter le commit de reformatage, qui ne contient évidemment aucune explication sur l'intention du code, seulement un message du type « Applique les standards de codage WordPress ». Il doit alors remonter manuellement, commit par commit, jusqu'à trouver la version antérieure au reformatage pour relancer un `git blame` sur cette version, une manipulation à la fois lente et sujette à erreur. > Chez WP Moderne, tout script de nettoyage de code qui touche à l'indentation d'un fichier entier s'accompagne désormais d'une note dans le message de commit invitant explicitement à relancer git blame avec -w sur ce fichier. ## Combiner -w avec le suivi du code déplacé L'option `-w` se combine efficacement avec deux autres options de `git blame` qui traitent un problème voisin : le déplacement ou la copie de code sans modification de son contenu. `-M` détecte les lignes déplacées à l'intérieur d'un même fichier, par exemple lors d'une réorganisation d'une classe PHP en plusieurs méthodes plus courtes, tandis que `-C` détecte les lignes copiées depuis un autre fichier du même commit, un cas fréquent lors de l'extraction d'une fonction commune vers un nouveau fichier utilitaire : ``` git blame -w -M -C includes/class-catalogue-produits.php ``` Cette combinaison représente la configuration la plus fidèle pour retrouver l'auteur réel d'un contenu logique, en excluant à la fois le bruit du formatage et celui des réorganisations structurelles qui ne changent pas le fond du code. ## Une limite à connaître : le seuil de détection de copie L'option `-C`, en particulier, a un coût en temps de calcul sur de gros dépôts, car elle demande à Git de comparer chaque bloc de lignes supprimées avec l'ensemble des autres fichiers du commit pour détecter une éventuelle copie. Sur un historique long et un fichier volumineux, l'exécution peut devenir sensiblement plus lente qu'un `git blame -w` simple. Il est donc raisonnable de réserver `-C` aux cas où une extraction de code est explicitement soupçonnée, plutôt que de l'ajouter systématiquement à chaque appel de `git blame` par habitude. ## Ce qu'il faut retenir L'option `-w` de `git blame` corrige un biais discret mais fréquent de l'attribution ligne par ligne : sans elle, un commit de reformatage global masque systématiquement les véritables auteurs du contenu logique d'un fichier. Cette option ne remplace pas une bonne discipline de commits séparés entre reformatage et changement fonctionnel, mais elle rattrape efficacement les projets où cette séparation n'a pas toujours été respectée, ce qui reste, en pratique, la majorité des projets qui vivent plusieurs années.