git apply fails with "patch does not apply" error

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?

Atchley

Are there any AbstractedPanel.java.rej files lying around? Typical this means that a line bot changed in the source as well as in the patch (here line 13 seems to be affected). – Wilda

No, I didn't find any *.rej files. – Atchley

Have you tried reporting a bug to [email protected]? None of the described options of Git apply work for me returning tons of errors. I had to fall back to WinMerge. – Intimidate

For me it meant I was git apply'ing a patch that was already in there FWIW...shame it doesn't give a more meaningful message... – Dunn

Answer 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.

Atchley

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? – Schistosome

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 – Tropous

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

@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. – Camarilla

@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. – Simpson

@Simpson 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. – Camarilla

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

@Simpson 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. – Camarilla

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

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 : https://mcmap.net/q/12553/-git-apply-fails-mysteriously-how-do-i-troubleshoot-fix – Loveridge

God. This is it. I'm so tired of working with patches. – Faustena

Answer 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.

Mock

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

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

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. – Hershel

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

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

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. – Swim

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 – Breakaway

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: – Epiphenomenon

Live saver, would give you more points if I could. – Jabin

Answer 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.

Afoul

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.) – Serotonin

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. – Typology

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. – Serieswound

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

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). – Eudora

@Eudora 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? – Afoul

@Afoul 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.) – Eudora

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

@PavanManjunath what's hg – Craver

@Craver Command line app for a git alternative called Mercurial. It's kind of the betamax to git's VHS [metaphor context here]. Actually a few days younger than git. – Afoul

@Craver hg is another open source control management system. Just like git. mercurial-scm.org – Serieswound

Answer 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

Pester

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 ? – Colly

@Colly 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") – Pester

@Colly 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 – Quadrennial

Answer 5

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

patch -p1 < example.patch

This helped me .

Abiding

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. – Huff

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

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

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

This is the way. Forget git patch – Tops

If you are on Windows you probably don't have patch but you can open and apply the .patch in TortoiseMerge or whatever, the point is, use something that's not git! – Alcazar

sometime this works, sometime others answers works. – Tartar

Answer 6

It happens when you mix UNIX and Windows git clients because Windows doesn't really have the concept of the "x" bit so your checkout of a rw-r--r-- (0644) file under Windows is "promoted" by the msys POSIX layer to be rwx-r-xr-x (0755). git considers that mode difference to be basically the same as a textual difference in the file, so your patch does not directly apply. I think your only good option here is to set core.filemode to false (using git-config).

Here's a msysgit issue with some related info: http://code.google.com/p/msysgit/issues/detail?id=164 (rerouted to archive.org's 3 Dec 2013 copy)

Louis

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

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. – Louis

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. – Atchley

Answer 7

Just use git apply -v example.patch to know the reasons of "patch does not apply". And then you can fix them one by one.

Pfeifer

Answer 8

In my case I was stupid enough to create the patch file incorrectly in the first place, actually diff-ing the wrong way. I ended up with the exact same error messages.

If you're on master and do git diff branch-name > branch-name.patch, this tries to remove all additions you want to happen and vice versa (which was impossible for git to accomplish since, obviously, never done additions cannot be removed).

So make sure you checkout to your branch and execute git diff master > branch-name.patch

Hystero

I made the same mistake, look at chimurai answer https://mcmap.net/q/12287/-git-apply-fails-with-quot-patch-does-not-apply-quot-error – White

Answer 9

git apply --reverse --reject example.patch

When you created a patch file with the branch names reversed:

ie. git diff feature_branch..master instead of git diff master..feature_branch

Zionism

Answer 10

If the patch is only partly applied, but not the entire patch. Make sure you are in the correct directory when applying the patch.

For example I created a patch file in the parent project folder containing the .git file. However I was trying to apply the patch at a lower level. It was only applying changes at that level of the project.

Mcbride

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 – Vano

@Mcbride what do you mean by this - I created a patch file in the parent project folder containing – Craver

@DhruvSaraswat how do you basically decide what is the correct directory to apply the patch ? – Craver

Answer 11

My issue is that I ran git diff, then ran git reset --hard HEAD, then realized I wanted to undo, so I tried copying the output from git diff into a file and using git apply, but I got an error that "patch does not apply". After switching to patch and trying to use it, I realized that a chunk of the diff was repeated for some reason, and after removing the duplicate, patch (and presumably also git apply) worked.

Orthogenetic

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

Answer 12

Make sure you are:

1. Running the git apply command from the root of the repository (weird, but that was the only correct solution for me)
2. You are running git apply without --check option (in that case only the check is executed, but the patch itself is not applied)

Hope that helps!

Interstellar

Answer 13

What I looked for is not exactly pointed out in here in SO, I'm writing for the benefit of others who might search for similar. I faced an issue with one file (present in old repo) getting removed in the repo. And when I apply the patch, it fails as it couldn't find the file to be applied. (so my case is git patch fails for file got removed) '#git apply --reject' definitely gave a view but didn't quite get me to the fix. I couldn't use wiggle as it is not available for us in our build servers. In my case, I got through this problem by removing the entry of the 'file which got removed in the repo' from patch file I've tried applying, so I got all other changes applied without an issue (using 3 way merge, avoiding white space errors), And then manually merging content of file removed into where its moved.

Hollerman