My diff contains trailing whitespace - how to get rid of it?

Question

I've tried editing a php file in TextWrangler with line endings set to Unix, in NetBeans, and in vim. When I save the diff to a patch and then try to apply it, it gives whitespace errors. When I type git diff I can see ^M at the ends of my lines, but if I manually remove these in vim, it says my patch file is corrupted, and then the patch doesn't apply at all.

I create a patch with the following command:

git diff > patchname.patch

And I apply it by checking out a clean version of the file to be patched and typing

git apply patchname.patch

How can I create this patch without whitespace errors? I've created patches before and never run into this issue.

Solution 1

Are you sure those are hard errors? By default, git will warn about whitespace errors, but will still accept them. If they are hard errors then you must have changed some settings. You can use the --whitespace= flag to git apply to control this on a per-invocation basis. Try

git apply --whitespace=warn patchname.patch

That will force the default behavior, which is to warn but accept. You can also use --whitespace=nowarn to remove the warnings entirely.

The config variable that controls this is apply.whitespace.

---

For reference, the whitespace errors here aren't errors with your patch. It's a code style thing that git will, by default, complain about when applying patches. Notably, it dislikes trailing whitespace. Similarly git diff will highlight whitespace errors (if you're outputting to a terminal and color is on). The default behavior is to warn, but accept the patch anyway, because not every project is fanatical about whitespace.

Solution 2

git apply --reject --whitespace=fix mychanges.path

Solution 3

Try patch -p1 < filename.patch

Solution 4

Many times i have faced such issues when my team mate works on Linux/Windows or uses git send-email.

I always used to follow below command.

git apply -3 --whitespace=fix yourpatch.patch

or

git am -s -3 --whitespace=fix yourpatch.patch

-3 option will try three-way merge and it will help to solve other issues also.

Solution 5

the one line solution is:

emacs <filename> -f delete-trailing-whitespace -f save-buffer -f kill-emacs

source: https://wiki.gnome.org/Projects/GnomeShell/Development/WorkingWithPatches

View more solutions

Comments

[beth]

I understand that. However, I am confused as to where this whitespace is coming from. I didn't ask whether I should care about it, I asked how to fix it.

[Lily Ballard]

The whitespace is coming from the patch you're trying to apply. Which means it came from the diff you originally took.

[beth]

I know that. I am trying to find out how to create a diff without ending whitespace in it.

[Lily Ballard]

@beth: By, uh, removing the trailing whitespace in your source before creating the diff? Or you could just go ahead and use git apply --whitespace=fix patchname.patch, which will fix the whitespace errors it sees for you.

[beth]

Okay, just imagine that it is important to me not to have trailing whitespace at all. I mentioned attempting to remove it in several different editors. "By removing trailing whitespace" isn't really an answer to the question "how do I remove trailing whitespace". Sorry if I was unclear.

[Lily Ballard]

@beth: You mentioned trying to remove it from the diff. Manually editing diffs is a tricky process. But again, you can use git apply --whitespace=fix patchname.patch and git will fix the whitespace for you.

[beth]

What does this do? Where does the .diff file come from?

[flash]

its just a patch file

[beth]

I think your carat is backwards or something is missing.

[Erwin Coumans]

The patch command doesn't tell git that files have been added or removed. The suggestion by zednight (git apply --reject --whitespace=fix mychanges.path) is better, because it deals with added and removed files properly.

[Darian Lewin]

Useful to automatically fix whitespace errors. --whitespace=fix ensures whitespace errors are fixed before path is applied, and --reject ensures atomicity so no working directory files are modified if patch will not apply. Source: git-scm.com/docs/git-apply

[Martin R.]

The original sign (<) is correct, this way the destination files are determined by the patch file itself. See man patch: patch [options] [originalfile [patchfile]] but usually just patch -pnum <patchfile

[alper]

White space was at on the very last line but it didn't fix it

[alper]

Seems like this is not working if the very last line is only a newline

[KansaiRobot]

Actually I think it has not been yet

[Jalal]

Please add more details to your answer.