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?

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). — Rudi, Jan 24 '11 at 10:44
Have you tried reporting a bug to git@vger.kernel.org? None of the described options of Git apply work for me returning tons of errors. I had to fall back to WinMerge. — Puterdo Borato, Sep 24 '20 at 19:21
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... — rogerdpack, Apr 05 '23 at 20:55

score 653 · Answer 1 · edited Jun 20 '21 at 10:39

653

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.

edited Jun 20 '21 at 10:39

Bharat Pahalwani

1,404
3
25
40

answered Mar 13 '13 at 02:16

user1028904

7,450
1
16
7

11

This actually worked better for me because it didn't completely modify my file – Wayne Werner Jan 07 '14 at 21:05
14

This is great. Just rejects what it cannot solve itself and you can then just modify the rejected files manually. – Dennis Jul 03 '14 at 14:27
1

patch -p1 .orig and .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. – gaoithe Aug 27 '14 at 16:29
10

this command creates `.rej` files when can't automatically detect how to apply a patch. You could use [wiggle](http://linux.die.net/man/1/wiggle) to resolve such issues. – goodniceweb Apr 30 '16 at 11:21
1

This worked great for applying a patch created on Windows to a Git repo on a Mac (fixed the newline differences automatically). – ecraig12345 Apr 13 '17 at 00:15
19

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. – Oliver Jan 25 '19 at 15:24
1

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 – Rishiraj Purohit May 05 '21 at 08:56
2

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: – silopolis Jun 03 '22 at 10:02

score 402 · Accepted Answer · answered Jan 28 '11 at 20:32

402

Johannes Sixt from the msysgit@googlegroups.com mailing list suggested using following command line arguments:

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

This solved my problem.

answered Jan 28 '11 at 20:32

Glory to Russia

17,289
56
182
325

31

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? – skrebbel Apr 13 '11 at 11:43
1

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 – tjb May 11 '12 at 10:50
3

also try `-C1` switch for apply, it reduces the context around additions that are regarded as important. – Amir Ali Akbari Dec 23 '12 at 13:05
1

@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. – Eric Walker Mar 13 '13 at 03:24
3

@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. – jwg Mar 21 '13 at 09:30
@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. – Eric Walker Mar 22 '13 at 03:39
@EricWalker But does 'appropriately' mean CR or CR/LF ? ;) – jwg Mar 22 '13 at 09:35
@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. – Eric Walker Mar 22 '13 at 18:55
3

This helps sometimes. But other times, I still get the "patch does not apply", even though the patch should apply without issues. – Thomas Levesque Apr 18 '16 at 09:56
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://stackoverflow.com/a/62433613/199593 – edigu Jun 17 '20 at 16:25
God. This is it. I'm so tired of working with patches. – Hitesh Kumar Saini Dec 28 '22 at 12:31

score 254 · Answer 3 · answered Dec 11 '17 at 15:46

254

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.

answered Dec 11 '17 at 15:46

ruffin

16,507
9
88
138

4

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.) – Christia May 16 '18 at 05:02
3

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. – steinybot Jul 12 '18 at 04:17
26

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. – Pavan Manjunath Aug 03 '18 at 01:48
14

Definitely, the best solution. Let the user resolve his own conflicts! – Mosh Feu Dec 18 '18 at 15:51
3

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 apply```However, on the same patch file, it will apply if I ignore whitespace (then I have to go fix up the whitespace). – Nathan Sep 10 '20 at 16:36
@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](https://stackoverflow.com/a/4832785/1028230) works are in a wholly separate set than those whose problems are solved by this answer? – ruffin Sep 10 '20 at 18:34
@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.) – Nathan Sep 10 '20 at 18:48
3

`--3way` is way better than `--reject` as you end up with normal merge conflict that every git developer is used to resolve. – Mecki Nov 18 '21 at 20:45

score 65 · Answer 4 · edited Jun 19 '14 at 20:52

65

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

edited Jun 19 '14 at 20:52

Mathias Bynens

144,855
52
216
248

answered Sep 12 '13 at 13:26

Ivan Voroshilin

5,233
3
32
61

9

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 ? – coding_idiot Apr 07 '15 at 05:18
1

@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") – Ivan Voroshilin Apr 23 '15 at 11:19
5

@coding_idiot you could use [wiggle](http://linux.die.net/man/1/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 Apr 30 '16 at 11:19

score 41 · Answer 5 · answered Mar 28 '18 at 14:26

41

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

patch -p1 < example.patch

This helped me .

answered Mar 28 '18 at 14:26

Pini Cheyni

5,073
2
40
58

5

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. – sudo rm -rf slash Nov 09 '18 at 22:25
1

@sudorm-rfslash, why are we not supposed to do this and why were you doing it nevertheless? – Black Feb 24 '20 at 08:15
`git: 'patch' is not a git command.` on `git version 2.21.1 (Apple Git-122.3)` – Sridhar Sarnobat Mar 09 '20 at 18:10
3

@SridharSarnobat The command is `patch`, not `git patch`.See [patch(1)](https://man7.org/linux/man-pages/man1/patch.1.html) – HeySora Nov 17 '20 at 12:54
1

This is the way. Forget `git patch` – Charlton Provatas Oct 11 '22 at 04:21
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! – c z Nov 25 '22 at 12:01
sometime this works, sometime others answers works. – jian Aug 24 '23 at 02:02

score 18 · Answer 6 · edited Aug 16 '17 at 17:25

18

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)

edited Aug 16 '17 at 17:25

ruffin

16,507
9
88
138

answered Jan 22 '11 at 20:02

Ben Jackson

90,079
9
98
150

2

I tried to run the command "git config core.filemode false", but it didn't help - I'm still getting the same message. – Glory to Russia Jan 22 '11 at 20:19
1

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. – Ben Jackson Jan 22 '11 at 20:25
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. – Glory to Russia Jan 22 '11 at 22:46

score 12 · Answer 7 · answered Jul 29 '21 at 11:26

12

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.

answered Jul 29 '21 at 11:26

secfree

4,357
2
28
36

score 8 · Answer 8 · answered Mar 23 '18 at 11:58

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

I made the same mistake, look at chimurai answer https://stackoverflow.com/a/65357332/1248565 — fbiagi, Apr 29 '21 at 22:01

score 6 · Answer 9 · answered Dec 18 '20 at 12:46

6

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

answered Dec 18 '20 at 12:46

chimurai

1,285
1
16
18

score 1 · Answer 10 · answered Jun 01 '21 at 14:06

1

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.

answered Jun 01 '21 at 14:06

MShubat

491
6
5

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 – Dhruv Saraswat Jun 15 '22 at 09:29

score 0 · Answer 11 · answered Jun 18 '20 at 05:16

0

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.

answered Jun 18 '20 at 05:16

Solomon Ucko

5,724
3
24
45

@VirendraKumar I manually edited the diff file to remove the duplicate lines. I then used `patch`. (`git apply` would probably also work.) – Solomon Ucko Jul 15 '20 at 21:05

score 0 · Answer 12 · answered Aug 25 '23 at 11:39

Make sure you are:

Running the git apply command from the root of the repository (weird, but that was the only correct solution for me)
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!

score -1 · Answer 13 · answered Apr 30 '20 at 07:09

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.

git: patch does not apply

13 Answers13

Explanation

Linked