What does "1 line adds whitespace errors" mean when applying a patch?

Question

I'm editing some markdown files of a cloned remote repository, and wanted to test creating and applying patches from one branch to another. However, every time I make any change at all, I get the following message during git apply:

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

(This is happening on my Mac, and I don't know where the original code was created.)

What does the warning message mean, and do I need to care?

Prefer

Related ("why?"): #1583906 – Droopy

Answer 1

You don't need to care.

The warning enacts a standard of cleanliness of text files in regard to whitespace, the kind of thing that many programmers tend to care about. As the manual explains:

What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors.

By default, the command outputs warning messages but applies the patch.

So, the "error" means that the change introduces a trailing whitespace, a whitespace-only line, or a space that precedes a tab. Other than that fact, there is nothing erroneous about the change, and it will apply cleanly and correctly. In other words, if you don't care about the "incorrect" whitespace, feel free to ignore the warning or turn it off with git config apply.whitespace nowarn.

Lesh

Thanks. The strange part is I'm quite positive the change doesn't introduce any new whitespace issues - I literally inserted a single word in the middle of a sentence.. – Prefer

Look at the commit with git show — if your git does colors, you will see the offending whitespace come up in angry red. Also, git show --word-diff will show you not only the line change, but insertions in the middle of the line, which should show whether the patch really only adds a word in the middle, or if it also adds a trailing whitespace. – Lesh

You don't need to care. But you should. Trailing whitespace should be eradicated. – Lelialelith

Except the OP adds no new trailing whitespace, only modifies what already exists. – Lesh

I have seen this prop up in a similar situation when the line endings are Windows style CRLFs instead of Unix ones. – Chian

@Prefer If you add a word in the middle of a line, and the line already has trailing whitespace, that may trigger the warning. – Hystero

The question is, when you see 5 of these merging branches, how do you know where these are? There is no filenames as far as I can tell. I could only find one by grepping, the rest I had no luck. But line numbers did not match. – Inadvisable

I had success with git config --global apply.whitespace nowarn, but not with git config core.whitespace nowarn. – Braze

OK, so what if you do care? How do you find the errors? – Lee

@EdwardFalk git diff will show the errors in red. – Lesh

True, but merge operations don't. They just display the ambiguous errors shown in the question. – Lee

@EdwardFalk This question is about the behavior of git apply. Can you be more specific about what you mean by "merge operations"? – Lesh

... and if you do care, it's easy to fix. Assuming you just committed those whitespace warned offenders: 1) identify the culprits using git show 2) git add --patch [fix just the whitespace errors, leave everything else alone] 3) git commit --amend 4) Run git show and achieve whitespace zen. Note that you could also fix them by backing out your staging, but there are times you may not want to do that. (Say, you're in the middle of another git add --patch session.) – Polyhydric

@user4815162342, why is this the default setting though? – Haveman

@Haveman Good question. I think it's because trailing whitespace is almost always introduced accidentally and creates much problems with VCS when applying diffs and merging branches. git developers likely wanted their VCS to detect and correct the problem at the earliest opportunity, when reviewing the patch. But I don't have citations for any of this, so take it with a grain of salt. It could also be a personal preference by the git developers, some people are quite fussy about whitespace. – Lesh

Answer 2

One case when you could legitimately care is when you want to differentiate between "old" whitespase error (that you might want to keep for legacy reason) and "new" whitespace errors (that you want to avoid).

To that effect, Git 2.5+ (Q2 2015) will propose a more specific option for whitespace detection.

See commits 0e383e1, 0ad782f, and d55ef3e [26 May 2015] by Junio C Hamano (gitster).
^{(Merged by Junio in commit 709cd91, 11 Jun 2015)}

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

Traditionally, we only cared about whitespace breakages introduced in new lines.
Some people want to paint whitespace breakages on old lines, too. When they see a whitespace breakage on a new line, they can spot the same kind of whitespace breakage on the corresponding old line and want to say "Ah, those breakages are there but they were inherited from the original, so let's not touch them for now."

Introduce --ws-error-highlight=<kind> option, that lets them pass a comma separated list of old, new, and context to specify what lines to highlight whitespace errors on.

The documentation now includes:

--ws-error-highlight=<kind>

Highlight whitespace errors on lines specified by <kind> in the color specified by color.diff.whitespace.
<kind> is a comma separated list of old, new, context.
When this option is not given, only whitespace errors in new lines are highlighted.

E.g. --ws-error-highlight=new,old highlights whitespace errors on both deleted and added lines.
all can be used as a short-hand for old,new,context.

For instance, the old commit had one whitespace error (bbb), but you can focus on the new errors only (at the end of still bbb and ccc):

(test done after t/t4015-diff-whitespace.sh)

---

With Git 2.26 (Q1 2020), the diff-* plumbing family of subcommands now pay attention to the diff.wsErrorHighlight configuration, which has been ignored before; this allows "git add -p" to also show the whitespace problems to the end user.

See commit da80635 (31 Jan 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit df04a31, 14 Feb 2020)}

diff: move diff.wsErrorHighlight to "basic" config

^{Signed-off-by: Jeff King}

We parse diff.wsErrorHighlight in git_diff_ui_config(), meaning that it doesn't take effect for plumbing commands, only for porcelains like git diff itself.
This is mildly annoying as it means scripts like add--interactive, which produce a user-visible diff with color, don't respect the option.

We could teach that script to parse the config and pass it along as --ws-error-highlight to the diff plumbing. But there's a simpler solution.

It should be reasonably safe for plumbing to respect this option, as it only kicks in when color is otherwise enabled. And anybody parsing colorized output must already deal with the fact that color.diff.* may change the exact output they see; those options have been part of git_diff_basic_config() since its inception in 9a1805a872 (add a "basic" diff config callback, 2008-01-04, Git v1.5.4-rc3).

So we can just move it to the "basic" config, which fixes add--interactive, along with any other script in the same boat, with a very low risk of hurting any plumbing users.

Mourant

Answer 3

The whitespace error with visual images is shown here.

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

Sarina

Answer 4

It works for me :

git config apply.whitespace fix

before every commit use :

git add -up .

Limbic

Answer 5

Because line begining with TAB istead of SPACE. Go on patch file and replace TAB with SPACE. E.g. on vim on line + from patch file type x to remove space and not remove sign + and insert space (CTRL) on eqiv to original size.

Areaway

-1 You really think git would complain about Linus style tab indentation? The only legit use of tab, if any, is precisely the beginning of the line. – Antipas