I have a shallow clone, on which i made three commits.
Here is the log:
$ git log --oneline --graph --decorate --all
* d3456fd (HEAD, maste
ok. the following worked .
$ git am -3 --ignore-whitespace /c/temp/git/format_since_origin.patch
Applying: patch 1
Applying: patch 2
Applying: patch 3
Why would i need to ignore whitespace while applying?
Note that one rationale for having to ignore whitespace was (June 2010):
What it does is enable the
GMail -> download -> git-am workflow
.
GMail (and doubtless countless other) E-Mail providers introduce whitespace at the beginning of raw E-Mail messages, while otherwise leaving them intact.
As mentioned in "git am/format-patch: control format of line endings", you can try a:
git am --keep-cr
That wouldn't require you to ignore whitespace (warning only).
The OP maxmelbin confirms in the comments that the following works:
git am -3 --keep-cr --committer-date-is-author-date /c/temp/git/format_since_origin.patch
When git apply is working normally, you get no output at all:
$ git apply example.patch
[nothing returned]
If you want to see what's going on behind the scenes, you can use the -v (verbose) flag:
$ git apply -v example.patch
Checking patch includes/common.inc...
Applied patch includes/common.inc cleanly.
However, if running git apply from within your own local git working copy, it's possible that even with the -v (verbose) flag, git apply will do nothing, and give no output. If this happens, please check your location in the directory tree - git apply may work from another location.
An alternative to git apply is to use the patch command:
$ patch -p1 < example.patch
Here is other output the git apply command can generate, and what it means. Patch does not apply
$ git apply example.patch
error: patch failed: includes/common.inc:626
error: includes/common.inc: patch does not apply``
Git couldn't apply the changes in the patch because it wasn't able to find the line(s) of code in question; they must have been changed or removed by another commit. Try these things:
Make sure the patch hasn't already been applied. Look for it in git-log or simply examine the code to see if the change(s) are already present. If they are, you're done. If they aren't or if only some of them are, try something else:
Use patch -p1 < filename.patch
. Whereas git-apply altogether rejects a patch with any errors, patch -p1 works hunk by hunk, applying as many individual changes as it can. It backs up each file as filename.ext.orig before modifying it and saves rejected hunks in filename.ext.rej
. Discard the .orig files and manually apply the changes left in the .rej. This is an easy strategy for small patches.