Co oznacza „1 wiersz dodaje błędy spacji” podczas stosowania poprawki?

Edytuję niektóre pliki markdown sklonowanego zdalnego repozytorium i chciałem przetestować tworzenie i stosowanie poprawek z jednej gałęzi do drugiej. Jednak za każdym razem, gdy w ogóle wprowadzam jakąkolwiek zmianę, w trakcie git apply:

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

(Dzieje się to na moim Macu i nie wiem, gdzie został utworzony oryginalny kod).

Co oznacza komunikat ostrzegawczy i czy muszę się tym przejmować?

Nie musisz się tym przejmować.

Ostrzeżenie to ustanawia standard czystości plików tekstowych w odniesieniu do białych znaków, tego rodzaju rzeczy, na których zależy wielu programistom. Jak wyjaśnia podręcznik :

To, co jest uważane za błędy białych znaków, jest kontrolowane przez konfigurację core.whitespace. Domyślnie końcowe białe spacje (w tym wiersze, które składają się wyłącznie z białych znaków) i znak spacji, po którym bezpośrednio następuje znak tabulacji wewnątrz początkowego wcięcia wiersza, są traktowane jako błędy związane z białymi znakami.

Domyślnie polecenie wyświetla komunikaty ostrzegawcze, ale stosuje poprawkę.

Zatem „błąd” oznacza, że ​​zmiana wprowadza na końcu biały znak, linię zawierającą tylko białe znaki lub spację poprzedzającą tabulator. Poza tym nie ma nic błędnego w zmianie, a zastosuje się ona czysto i poprawnie. Innymi słowy, jeśli nie przejmujesz się „niepoprawnymi” białymi znakami, możesz zignorować ostrzeżenie lub wyłączyć je za pomocą git config apply.whitespace nowarn.

Jednym z przypadków, w których można by się tym przejmować, jest rozróżnienie między „starym” błędem białych znaków (który warto zachować ze względu na starszą wersję) i „nowymi” błędami związanymi z białymi znakami (których należy unikać).

W tym celu Git 2.5+ (Q2 2015) zaproponuje bardziej szczegółową opcję wykrywania białych znaków.

Zobacz commits 0e383e1 , 0ad782f i d55ef3e [26 maja 2015] autorstwa Junio ​​C Hamano ( gitster) .
^{(Scalone przez Junio w zatwierdzeniu 709cd91 , 11 czerwca 2015 r.)}

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

Tradycyjnie interesowały nas tylko przerwy w postaci białych znaków wprowadzane w nowych wierszach.
Niektórzy ludzie chcą również malować przerwy w białych znakach na starych liniach. Kiedy widzą przerwanie białych znaków w nowej linii, mogą zauważyć ten sam rodzaj złamania białych znaków w odpowiedniej starej linii i chcą powiedzieć „Ach, te pęknięcia istnieją, ale zostały odziedziczone z oryginału, więc nie dotykajmy ich teraz."

Wprowadzić --ws-error-highlight=<kind>opcję, która pozwala im przejść przecinek listę oddzielone old, newi contextokreślić, jakie linie podświetleniem białymi znakami na błędy.

Dokumentacja obejmuje obecnie :

--ws-error-highlight=<kind>

Podświetlaj błędy białych znaków w liniach określonych przez <kind>w kolorze określonym przez color.diff.whitespace.
<kind>jest oddzielony przecinkami lista old, new, context.
Jeśli ta opcja nie jest podana, newpodświetlane są tylko błędy w postaci białych znaków w wierszach.

Np. --ws-error-highlight=new,oldPodświetla błędy białych znaków w usuniętych i dodanych wierszach.
allmoże być używany jako krótka ręka dla old,new,context.

Na przykład stare zatwierdzenie miało jeden błąd spacji ( bbb), ale możesz skupić się tylko na nowych błędach (na końcu still bbbi ccc):

(test wykonany później t/t4015-diff-whitespace.sh)

W Git 2.26 (Q1 2020) diff-*rodzina podpoleceń dotyczących hydrauliki zwraca teraz uwagę na diff.wsErrorHighlightkonfigurację, która była wcześniej ignorowana; pozwala to " git add -p" również pokazać problemy z białymi znakami użytkownikowi końcowemu.

Zobacz commit da80635 (31 stycznia 2020) autorstwa Jeffa Kinga ( peff) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu df04a31 , 14 lutego 2020 r.)}

diff: przenieś diff.wsErrorHighlight do "podstawowej" konfiguracji

^{Podpisał: Jeff King}

Analizujemy diff.wsErrorHighlight w git_diff_ui_config(), co oznacza, że ​​nie ma to wpływu na polecenia hydrauliczne, tylko w przypadku porcelany takiej git diffjak ona.
Jest to nieco denerwujące, ponieważ oznacza, że ​​skrypty takie jak add--interactive, które tworzą widoczne dla użytkownika różnice z kolorem, nie uwzględniają tej opcji .

Moglibyśmy nauczyć tego skryptu analizować konfigurację i przekazywać ją razem --ws-error-highlightz instalacją różnicową. Ale jest prostsze rozwiązanie.

Przestrzeganie tej opcji powinno być rozsądnie bezpieczne, ponieważ włącza się ona tylko wtedy, gdy kolor jest włączony. Każdy, kto analizuje pokolorowane wyjście, musi już poradzić sobie z faktem, że color.diff.*może to zmienić dokładny wynik, który widzi; opcje te były częścią git_diff_basic_config()od momentu ich powstania w 9a1805a872 (dodaj "podstawowe" wywołanie zwrotne konfiguracji diff, 2008-01-04, Git v1.5.4-rc3).

Możemy więc po prostu przenieść go do „podstawowej” konfiguracji, która naprawia add--interactive, wraz z każdym innym skryptem na tej samej łodzi, przy bardzo niskim ryzyku zranienia użytkowników hydrauliki.

Tutaj pokazano błąd białych znaków w obrazach wizualnych.

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

Ponieważ linia TABzaczynająca się od SPACE. Idź na pliku łaty i wymienić TABz SPACE. Np. W vim on line + z pliku łatki typu x, aby usunąć spację i nie usunąć znaku + i wstaw spację (CTRL) na eqiv do oryginalnego rozmiaru.