git: patch does not apply

Question

I have a certain patch called my_pcc_branch.patch.

When I try to apply it, I get following message:

$ git apply --check my_pcc_branch.patch
warning: src/main/java/.../AbstractedPanel.java has type 100644, expected 100755
error: patch failed: src/main/java/.../AbstractedPanel.java:13
error: src/main/java/.../AbstractedPanel.java: patch does not apply

What does it mean?

How can I fix this problem?

Solution 1

Johannes Sixt from the [email protected] mailing list suggested using following command line arguments:

git apply --ignore-space-change --ignore-whitespace mychanges.patch

This solved my problem.

Solution 2

git apply --reject --whitespace=fix mychanges.patch worked for me.

Explanation

The --reject option will instruct git to not fail if it cannot determine how to apply a patch, but instead to apply the individual hunks it can apply and create reject files (.rej) for hunks it cannot apply. Wiggle can "apply [these] rejected patches and perform word-wise diffs".

Additionally, --whitespace=fix will warn about whitespace errors and try to fix them, rather than refusing to apply an otherwise applicable hunk.

Both options together make the application of a patch more robust against failure, but they require additional attention with respect to the result.

For the whole documentation, see https://git-scm.com/docs/git-apply.

Solution 3

When all else fails, try git apply's --3way option.

git apply --3way patchFile.patch

--3way
When the patch does not apply cleanly, fall back on 3-way merge if the patch records the identity of blobs it is supposed to apply to, and we have those blobs available locally, possibly leaving the conflict markers in the files in the working tree for the user to resolve. This option implies the --index option, and is incompatible with the --reject and the --cached options.

Typical fail case applies as much of the patch as it can, and leaves you with conflicts to work out in git however you normally do so. Probably one step easier than the reject alternative.

Solution 4

This command will apply the patch not resolving it leaving bad files as *.rej:

git apply --reject --whitespace=fix mypath.patch

You just have to resolve them. Once resolved run:

git -am resolved

Solution 5

Try using the solution suggested here: https://www.drupal.org/node/1129120

patch -p1 < example.patch

This helped me .

View more solutions

Comments

[Glory to Russia]

I tried to run the command "git config core.filemode false", but it didn't help - I'm still getting the same message.

[Ben Jackson]

Assuming you have no un-committed changes in your tree, try git reset --hard HEAD to force git to re-checkout your files with the new option in effect.

[Glory to Russia]

Just tried it out execute "git reset --hard HEAD". It was successful (I saw the message "HEAD is now at ..."), but the problem with "git apply" persists.

[skrebbel]

Can anyone help me and explain why this works? The other answer did not work for me, and I had the exact same problem as what the question asker describes. What do file attributes have to do with ignoring whitespace?

[tjb]

Using windows powershell A patch made with git diff was successfully applied as follows: git diff HEAD..613fee -- myfile.xml | git apply --ignore-space-change --ignore-whitespace, whereas first saving the diff output as a file did not work, in case anyone runs into the same problem

[Amir Ali Akbari]

also try -C1 switch for apply, it reduces the context around additions that are regarded as important.

[Eric Walker]

@skrebbel: no doubt due to the line endings differing between the local file system and the remote repo. Under some configurations Git will do magic with Windows-UNIX line ending translation (I advise against this). Editors should be configured not to translate. File attributes are probably not relevant. There is the ".gitattributes" file, but this seems overkill for common scenarios.

[jwg]

@EricWalker, git magic with CR/LF isn't necessarily a bad thing. The alternative can be that half of your changesets consists of every single line in every file that was touched being changed from one line ending to the other, with the actual change buried somewhere in the middle.

[Eric Walker]

@jwg I agree that huge changesets that only involve line endings is a problem. There are several ways to address this -- CR/LF conversion and configuring editors appropriately are two of them. Personally I like the editor option -- it feels cleaner to me, and contributors to a project should be on top of this detail. It's a preference rather than a rule.

[jwg]

@EricWalker But does 'appropriately' mean CR or CR/LF ? ;)

[Eric Walker]

@jwg Ha! I guess we all have our opinions there. :) More seriously, I think it depends upon the consensus of the project. In this approach, you just decide on a standard line ending for the remote repo and live with it. It doesn't matter which one.

[Wayne Werner]

This actually worked better for me because it didn't completely modify my file

[Dennis]

This is great. Just rejects what it cannot solve itself and you can then just modify the rejected files manually.

[gaoithe]

patch -p1 <mychanges.patch # applies changes chunk by chunk. If changes fail a <sourcefile>.orig and <sourcefile>.rej patch are created and you can apply changes manually. I'm guessing git apply --reject does the same and --whitespace=fix is magically better.

[coding_idiot]

how to resolve *.rej - all I can find is to make the changes manually in the source file & delete these .rej files. Any other way ?

[Ivan Voroshilin]

@coding_idiot As usual, Just check the .rej files, compare them with the conflicting files and finally add the fixed files to the index (with "git add FIXED_FILES")

[Thomas Levesque]

This helps sometimes. But other times, I still get the "patch does not apply", even though the patch should apply without issues.

[goodniceweb]

@coding_idiot you could use wiggle to resolve it. For example: wiggle --replace path/to/file path/to/file.rej. This command will apply changes from .rej file to original file. Also it creates a copy of original file, like path/to/file.porig. Please, checkout documentation to get more info about wiggle

[goodniceweb]

this command creates .rej files when can't automatically detect how to apply a patch. You could use wiggle to resolve such issues.

[ecraig12345]

This worked great for applying a patch created on Windows to a Git repo on a Mac (fixed the newline differences automatically).

[Christia]

This is the answer that worked for me. The file I was patching didn't reflect the changes that I generated the patch from (because I deleted the changes after I created the patch.)

[steinybot]

Nice general solution. The 3way diff didn't look like it normally does so a little confused by that but never the less this gave me the ability to resolve the conflict and get the patch to apply.

[Pavan Manjunath]

I think this --3way should be the default behavior. When patching fails, at least tell me what failed so that I can manually fix it. git apply just fails and doesn't report why something fails. I couldn't even find *.rej files like the ones hg generates.

[sudo rm -rf slash]

I know you're not supposed to do this, but THANK YOU SO MUCH! Saved me hours. I was getting "patch does not apply" and all sorts of errors.

[Mosh Feu]

Definitely, the best solution. Let the user resolve his own conflicts!

[Oliver]

This answer does not explain anything, in particular in which cases it will work. People, you really have to be more demanding of answer quality, this is SO not a forum.

[Black]

@sudorm-rfslash, why are we not supposed to do this and why were you doing it nevertheless?

[Sridhar Sarnobat]

git: 'patch' is not a git command. on git version 2.21.1 (Apple Git-122.3)

[E. T.]

This is a very dangerous command that can remove old lost commits forever from the reflog. If your repo is in a shaky state, DO NOT APPLY THIS.

[edigu]

Actually whitespaces are counts and they are part of the changeset! Ignoring them is just a workaround rather than a solution and ignoring them may not applicable in all cases. Today I hit a similar issue and explained the details here : stackoverflow.com/a/62433613/199593

[Solomon Ucko]

@VirendraKumar I manually edited the diff file to remove the duplicate lines. I then used patch. (git apply would probably also work.)

[Nathan]

Doesn't work for me in the case where the issues are caused by whitespace differences. I never get a prompt, and --3way doesn't actually apply anything. error: patch failed: Foo.cs:4 Falling back to three-way merge... error: patch failed: Foo.cs:4 error: Foo.cs: patch does not applyHowever, on the same patch file, it will apply if I ignore whitespace (then I have to go fix up the whitespace).

[ruffin]

@Nathan Well, I did say "When all else fails" ;^D. But more usefully, if you'll put up the two files on paste.ee or something, I can certainly take a look. But I think you might be arguing for git apply --ignore-space-change --ignore-whitespace --3way patchfile.patch by identifying the people for whom Mentiflectax's answer works are in a wholly separate set than those whose problems are solved by this answer?

[Nathan]

@ruffin Fair enough :-). Not necessarily arguing for any particular answer - I think many of the answers here apply in different situations. I'm just a bit confused as to why --3way failed in the scenario I encountered. I'd have to cleanup the files to remove confidential info before I could paste them, so I'll see if I can duplicate the issue with a non-confidential file. (I have suspicions that there might be something different in the local git configs on different machines that's leading to the whitespace issue in the first place.)

[HeySora]

@SridharSarnobat The command is patch, not git patch.See patch(1)

[fbiagi]

I made the same mistake, look at chimurai answer stackoverflow.com/a/65357332/1248565

[Rishiraj Purohit]

Very Important: The .rej files are placed exactly near the file on which patch failed. They are visible in the git status and be sure to take care of them before commit

[Mecki]

--3way is way better than --reject as you end up with normal merge conflict that every git developer is used to resolve.

[Silopolis]

This, followed by wiggle --replace file file.rej and solving remaining conflicts in file (help by beautiful IDE support) fixed everything. Thanks a lot, made my day :pray:

[Dhruv Saraswat]

This put me in the right direction. I was in the incorrect directory when applying the patch, because of which the patch was not applying. Thanks