I am trying to apply a few patches to my repo, and getting message patch does not apply
unless I specify params --ignore-space-change --ignore-whitespace
. Some patches can't be applied even with these keys, it says there are conflicts to be solved manually. (but actually nothing conflicts there, auto merge must had solved this)
I have done an experiment: created a patch from a commit in my repo, reset master to the previous commit, tried to apply patch from the file. The same error message.
Any ideas, why this might happen?
UPD the commands are very simple:
git format-patch -o ../_patches 0f3bf7874c32b22256ae2d9dc00b1afd6464e43c
git reset --hard 0f3bf7874c32b22256ae2d9dc00b1afd6464e43c
git am ../_patches/0001-test2.patch
(this id refers to the first commit before last)
You need to pass the
--keep-cr
flag togit am
. It's unfortunate, but because of competing standards (email workflow versus local), there's really not much choice.You may want to try setting up a
.gitattributes
file as well. Trying to recreate your issue, I was able to get things to work when I specified the file as requiring CRLF. Note, without normalizing the files first, it did show the whole file as modified. I commonly use a.gitattributes
with this:You'll want to normalize your line ending according to the gitattributes man page. Another SO user ended up turning off
core.autocrlf
as well to get clean commits and patches.Trying to reproduce your bug
Looking at the patch file that was produced, I see this:
As you can see, the carriage returns (
^M
s) were kept in the patch. This is withcore.autocrlf=false
. Continuing on, I see:So the patch doesn't apply well out-of-the-box. Using
--keep-cr
was as expected though:Okay. So let's try this with
core.autocrlf=true
(in a different repository):The patch in this case had LF endings everywhere.
Aha! Looks like I've found the reason. The repository uses CRLF line endings, but format-patch creates patch files with LF's. When I create a repo from scratch with autocrlf=false and make the same experiment, I have the same problem. (looks like a bug in Git)
Any advise how to fix this?
UPD my solution was to create a fresh repository with autocrlf=true and re-import all changes from both repositories into it.