Que signifie "1 ligne ajoute des erreurs d'espacement" lors de l'application d'un correctif ?

Question

Je suis en train d'éditer quelques fichiers markdown d'un dépôt distant cloné, et je voulais tester la création et l'application de correctifs d'une branche à l'autre. Cependant, à chaque fois que je fais une modification quelconque, j'obtiens le message suivant pendant git apply :

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

(Cela se produit sur mon Mac, et je ne sais pas où le code original a été créé).

Que signifie le message d'avertissement et dois-je m'en préoccuper ?

Answer 1

Tu n'as pas besoin de t'en soucier.

L'avertissement édicte une norme de propreté des fichiers texte en ce qui concerne les espaces, le genre de chose dont de nombreux programmeurs ont tendance à se soucier. Comme le manuel explique :

Ce qui est considéré comme des erreurs d'espacement est contrôlé par la configuration de core.whitespace. Par défaut, les espaces blancs de fin de ligne (y compris les lignes qui ne sont constituées que d'espaces) et un espace immédiatement suivi d'un caractère de tabulation à l'intérieur de l'indentation l'indentation initiale de la ligne sont considérés comme des erreurs d'espacement.

Par défaut, la commande émet des messages d'avertissement mais applique le correctif.

L'"erreur" signifie donc que la modification introduit un espace à la fin de la ligne, une ligne comportant uniquement des espaces ou un espace précédant une tabulation. En dehors de ce fait, il n'y a rien d'erroné dans la modification, et elle s'appliquera proprement et correctement. En d'autres termes, si vous ne vous souciez pas des espaces blancs "incorrects", vous pouvez ignorer l'avertissement ou le désactiver à l'aide de la commande git config apply.whitespace nowarn .

Answer 2

Un cas où l'on pourrait légitimement s'en soucier est celui où l'on veut faire la différence entre les "anciennes" erreurs d'espacement (que l'on pourrait vouloir conserver pour des raisons d'héritage) et les "nouvelles" erreurs d'espacement (que l'on veut éviter).

À cet effet, Git 2.5+ (Q2 2015) proposera une option plus spécifique pour la détection des espaces blancs.

Voir commits 0e383e1 , 0ad782f y d55ef3e [26 mai 2015] par Junio C Hamano ( gitster ) .
(fusionné par Junio en commettre 709cd91 , 11 juin 2015)

diff.c : --ws-error-highlight=<kind> option

Traditionnellement, nous ne nous préoccupions que des ruptures d'espaces blancs introduites dans les nouvelles lignes.
Certaines personnes veulent peindre des ruptures d'espacement sur les anciennes lignes, aussi. Quand ils voient une rupture d'espace sur une nouvelle ligne, ils peuvent ligne, ils peuvent repérer le même type de rupture d'espace sur l'ancienne ligne correspondante. sur l'ancienne ligne correspondante et veulent dire "Ah, ces ruptures sont là mais elles ont été héritées de l'original, donc ne les touchons pas pour le moment".

Présentez --ws-error-highlight=<kind> qui leur permet de passer une liste séparée par des virgules de old , new y context pour spécifier les lignes sur lesquelles les erreurs d'espacement doivent être mises en évidence.

El La documentation comprend désormais :

--ws-error-highlight=<kind>

Mettre en évidence les erreurs d'espacement sur les lignes spécifiées par <kind> dans la couleur spécifiée par color.diff.whitespace .
<kind> est une liste séparée par des virgules de old , new , context .
Lorsque cette option n'est pas donnée, seules les erreurs d'espacement dans les fichiers new 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 un raccourci pour old,new,context .

Par exemple, l'ancien commit avait une erreur d'espacement ( bbb ), mais vous pouvez vous concentrer uniquement sur les nouvelles erreurs (à la fin de la commande still bbb y ccc ):

(test effectué après t/t4015-diff-whitespace.sh )

---

Avec la version 2.26 de Git (Q1 2020), les diff-* La famille des sous-commandes de plomberie fait désormais attention à l'option diff.wsErrorHighlight qui n'était pas prise en compte auparavant, ce qui permet à " git add -p "afin de montrer également à l'utilisateur final les problèmes d'espaces blancs.

Voir commettre da80635 (31 janvier 2020) par Jeff King ( peff ) .
(fusionné par Junio C Hamano -- gitster -- en commettre df04a31 14 février 2020)

diff : déplacer diff.wsErrorHighlight vers la configuration "basique".

Signé par : Jeff King

Nous analysons diff.wsErrorHighlight en git_diff_ui_config() ce qui signifie qu'il ne s'applique pas aux commandes de plomberie, mais uniquement aux commandes de porcelaine, telles que git diff lui-même.
Ceci est légèrement ennuyeux car cela signifie que des scripts comme add--interactive qui produisent une différence de couleur visible par l'utilisateur, ne respectent pas l'option .

Nous pourrions apprendre à ce script à analyser la configuration et à la transmettre en tant que --ws-error-highlight à la plomberie du différentiel. Mais il y a une solution plus simple.

Il devrait être raisonnablement sûr pour la plomberie de respecter cette option, car elle ne se déclenche que lorsque la couleur est autrement activée. Et toute personne qui analyse la sortie colorée doit déjà faire face au fait que color.diff.* peuvent modifier le résultat exact qu'ils voient ; ces options font partie de la stratégie de l'UE. git_diff_basic_config() depuis sa création 9a1805a872 (ajout d'un appel de configuration de diff "basique", 2008-01-04, Git v1.5.4-rc3).

Nous pouvons donc le déplacer vers la configuration "de base", qui corrige les problèmes suivants add--interactive ainsi que tout autre script dans le même bateau, avec un risque très faible de blesser les utilisateurs de la plomberie.

Answer 3

L'erreur d'espacement des blancs avec les images visuelles est montrée ici.

http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines

Answer 4

Cela fonctionne pour moi :

git config apply.whitespace fix

avant chaque utilisation de commit :

git add -up .

Answer 5

Parce que la ligne commençant par TAB iste de SPACE . Allez sur le fichier patch et remplacez TAB con SPACE . Par exemple, dans vim, sur la ligne + du fichier patch de type x, supprimer l'espace et non le signe + et insérer l'espace (CTRL) sur l'eqiv à la taille originale.