Cosa significa "1 riga aggiunge errori di spazi bianchi" quando si applica una patch?

Sto modificando alcuni file di markdown di un repository remoto clonato e volevo provare a creare e applicare patch da un ramo all'altro. Tuttavia, ogni volta che apporto qualsiasi modifica, ricevo il seguente messaggio durante git apply:

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

(Questo sta accadendo sul mio Mac e non so dove è stato creato il codice originale.)

Cosa significa il messaggio di avviso e devo preoccuparmi?

Non devi preoccuparti.

L'avvertimento stabilisce uno standard di pulizia dei file di testo per quanto riguarda gli spazi bianchi, il genere di cose a cui molti programmatori tendono a preoccuparsi. Come spiega il manuale :

Quelli che sono considerati errori di spazi bianchi sono controllati dalla configurazione core.whitespace. Per impostazione predefinita, gli spazi vuoti finali (comprese le righe costituite esclusivamente da spazi bianchi) e un carattere di spazio immediatamente seguito da un carattere di tabulazione all'interno del rientro iniziale della riga sono considerati errori di spazio.

Per impostazione predefinita, il comando emette messaggi di avviso ma applica la patch.

Quindi, l '"errore" significa che la modifica introduce uno spazio vuoto finale, una riga di soli spazi bianchi o uno spazio che precede una tabulazione. Oltre a questo fatto, non c'è nulla di sbagliato nella modifica e verrà applicata in modo pulito e corretto. In altre parole, se non ti interessa lo spazio "errato", sentiti libero di ignorare l'avvertimento o disattivarlo con git config apply.whitespace nowarn.

Un caso in cui potresti legittimamente preoccuparti è quando vuoi distinguere tra "vecchio" errore di spaziatura bianca (che potresti voler mantenere per motivi legacy) e "nuovo" errori di spazio bianco (che vuoi evitare).

A tal fine, Git 2.5+ (Q2 2015) proporrà un'opzione più specifica per il rilevamento degli spazi.

Vedere i commit 0e383e1 , 0ad782f e d55ef3e [26 maggio 2015] di Junio ​​C Hamano ( gitster) .
^{(Fusa da Junio nel commit 709cd91 , 11 giugno 2015)}

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

Tradizionalmente, ci interessavano solo le rotture degli spazi bianchi introdotte nelle nuove righe.
Alcune persone vogliono dipingere anche le rotture di spazi bianchi su vecchie linee. Quando vedono una rottura di spazi bianchi su una nuova riga, possono individuare lo stesso tipo di interruzioni di spazi bianchi sulla vecchia riga corrispondente e vogliono dire "Ah, quelle rotture ci sono ma sono state ereditate dall'originale, quindi non toccatele per adesso."

Introdurre --ws-error-highlight=<kind>l'opzione, che permette loro di passare una virgola elenco di separati old, newe contextdi specificare quali linee per evidenziare gli spazi errori su.

La documentazione ora include :

--ws-error-highlight=<kind>

Evidenzia gli errori di spazi bianchi sulle linee specificate da <kind>nel colore specificato da color.diff.whitespace.
<kind>è un elenco separato da virgole old, new, context.
Quando questa opzione non è data, newvengono evidenziati solo gli errori di spazi bianchi nelle righe.

Ad esempio, --ws-error-highlight=new,oldevidenzia gli errori di spazi bianchi su entrambe le righe eliminate e aggiunte.
allpuò essere usato come abbreviazione per old,new,context.

Ad esempio, il vecchio commit aveva un errore di spazio bianco ( bbb), ma puoi concentrarti solo sui nuovi errori (alla fine di still bbbe ccc):

(test fatto dopo t/t4015-diff-whitespace.sh)

Con Git 2.26 (Q1 2020), la diff-*famiglia di sottocomandi idraulici ora presta attenzione alla diff.wsErrorHighlightconfigurazione, che è stata ignorata in precedenza; questo permette a " git add -p" di mostrare anche i problemi di spazi vuoti all'utente finale.

Vedere commit da80635 (31 gennaio 2020) di Jeff King ( peff) .
^{(Fuso da Junio ​​C Hamano - gitster- in commit df04a31 , 14 febbraio 2020)}

diff: sposta diff.wsErrorHighlight nella configurazione "base"

^{Firmato da: Jeff King}

Analizziamo diff.wsErrorHighlight in git_diff_ui_config(), il che significa che non ha effetto per i comandi idraulici, solo per porcellane come lei git diff.
Questo è leggermente fastidioso in quanto significa che script come add--interactive, che producono un diff visibile dall'utente con il colore, non rispettano l'opzione .

Potremmo insegnare a quello script ad analizzare la configurazione e passarla --ws-error-highlightal sistema idraulico diff. Ma c'è una soluzione più semplice.

Dovrebbe essere ragionevolmente sicuro per l'impianto idraulico rispettare questa opzione, poiché entra in funzione solo quando il colore è altrimenti abilitato. E chiunque analizzi l'output colorato deve già occuparsi del fatto che color.diff.*potrebbe cambiare l'esatto output che vede; queste opzioni sono state parte di git_diff_basic_config()sin dal suo inizio in 9a1805a872 (aggiungere un callback di configurazione diff "di base", 2008-01-04, Git v1.5.4-rc3).

Quindi possiamo semplicemente spostarlo nella configurazione "di base", che corregge add--interactive, insieme a qualsiasi altro script nella stessa barca, con un rischio molto basso di danneggiare gli utenti idraulici.

L'errore di spazio bianco con le immagini visive è mostrato qui.

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

Perché la linea TABinizia con invece di SPACE. Vai sul file di patch e sostituiscilo TABcon SPACE. Ad esempio, su vim in linea + dal file di patch digitare x per rimuovere lo spazio e non rimuovere il segno + e inserire lo spazio (CTRL) su eqiv alla dimensione originale.