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?
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
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 apply --reject --whitespace=fix mychanges.patch worked for me.
The --reject option will instruct git to not fail if it cannot determine how to apply a patch, but instead to apply indivdual 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.
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.
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
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.
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
Try using the solution suggested here: https://www.drupal.org/node/1129120
patch -p1 < example.patch
This helped me .
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)
I have found this link
I have no idea why this works but I tried many work arounds and this is the only one that worked for me. In short, run the three commands below:
git fsck --full
git reflog expire --expire=now --all
git gc --prune=now
Source: Stackoverflow.com