git am 错误：“补丁不适用”

git am error: "patch does not apply"

提问by nanuqcz

I am trying to move several commits from one project to the second, similar one, using git.

我正在尝试使用 git 将多个提交从一个项目移动到第二个类似的项目。

So I created a patch, containing 5 commits:

所以我创建了一个补丁，包含 5 个提交：

git format-patch 4af51 --stdout > changes.patch

Then move the patch to second project's folder and wants to apply the patch:

然后将补丁移动到第二个项目的文件夹并想要应用补丁：

git am changes.patch 

...but it gives me error:

...但它给了我错误：

Applying: Fixed products ordering in order summary.
error: patch failed: index.php:17
error: index.php: patch does not apply
Patch failed at 0001 Fixed products ordering in order summary.
The copy of the patch that failed is found in:
   c:/.../project2/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

So I opened the index.php, but nothing changed there. I assume some >>>>>>>marks etc., like when resolving merge conflict, but no conflict was marked in the file. git statusgave me also empty list of changed files (only changes.patchwas there). So I run git am --continue, but another error appears:

所以我打开了 index.php，但那里没有任何变化。我假设有一些>>>>>>>标记等，比如解决合并冲突时，但文件中没有标记冲突。git status还给了我已更改文件的空列表（只有changes.patch在那里）。所以我运行git am --continue，但出现另一个错误：

Applying: Fixed products ordering in order summary.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort". 

I am using Windows 7 and newest git version "1.9.4.msysgit.1"

我使用的是 Windows 7 和最新的 git 版本“1.9.4.msysgit.1”

P.S. After few hours of googling, I found few solutions, but nothing works for me:

PS 经过几个小时的谷歌搜索，我找到了几个解决方案，但对我来说没有任何效果：

---

---

git am -3 changes.patch 

gives strange "sha1 information" error:

给出奇怪的“sha1信息”错误：

Applying: Fixed products ordering in order summary.
fatal: sha1 information is lacking or useless (index.php).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Fixed products ordering in order summary.
The copy of the patch that failed is found in:
   c:/.../project2/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort". 

---

---

git am changes.patch --ignore-whitespace --no-scissors --ignore-space-change

gives first error as above: "error: patch failed: index.php:17", but no conflict marks in index.phpwas added.

给出第一个错误，如上：“错误：补丁失败：index.php:17”，但没有index.php添加冲突标记。

回答by torek

What is a patch?

什么是补丁？

A patch is little more (see below) than a series of instructions: "add this here", "remove that there", "change this third thing to a fourth". That's whygit tells you:

补丁只是一系列指令（见下文）：“在此处添加”、“在那里删除”、“将第三个内容更改为第四个内容”。这就是为什么git 告诉你：

The copy of the patch that failed is found in:
c:/.../project2/.git/rebase-apply/patch

The copy of the patch that failed is found in:
c:/.../project2/.git/rebase-apply/patch

You can open that patch in your favorite viewer or editor, open the files-to-be-changed in your favorite editor, and "hand apply" the patch, using what you know(and git does not) to figure out how"add this here" is to be done when the files-to-be-changed now look little or nothing like what they did when they were changed earlier, with those changes delivered to you as a patch.

你可以在你最喜欢的查看器或编辑器中打开那个补丁，在你最喜欢的编辑器中打开要更改的文件，然后“手动应用”补丁，使用你知道的（而 git 不知道）来弄清楚如何“添加this here”将在要更改的文件现在看起来与之前更改时所做的几乎没有或完全不同时执行，这些更改作为补丁提供给您。

A little more

再来一点

A three-way merge introduces that "little more" information than the plain "series of instructions": it tells you what the originalversion of the file was as well. If your repository has the original version, your git can compare what youdid to a file, to what the patchsays to do to the file.

三向合并引入了比简单的“一系列指令”“多一点”的信息：它也告诉您文件的原始版本是什么。如果您的存储库具有原始版本，则您的 git 可以将您对文件所做的操作与补丁对文件所做的操作进行比较。

As you saw above, if you request the three-way merge, git can't find the "original version" in the other repository, so it can't even attemptthe three-way merge. As a result you get no conflict markers, and you mustdo the patch-application by hand.

正如你在上面看到的，如果你请求三向合并，git在另一个存储库中找不到“原始版本”，因此它甚至无法尝试三向合并。因此，您不会得到任何冲突标记，您必须手动完成补丁应用程序。

Using --reject

使用 --reject

When you have to apply the patch by hand, it's still possible that git can apply mostof the patch for you automatically and leave only a few pieces to the entity with the ability to reason about the code (or whatever it is that needs patching). Adding --rejecttells git to do that, and leave the "inapplicable" parts of the patch in rejection files. If you use this option, you must still hand-apply each failing patch, and figure out what to do with the rejected portions.

当您必须手动应用补丁时，git 仍然有可能自动为您应用大部分补丁，而仅将少数部分留给具有推理代码能力的实体（或任何需要修补的内容） . 添加--reject告诉 git 这样做，并将补丁的“不适用”部分留在拒绝文件中。 如果您使用此选项，您仍然必须手动应用每个失败的补丁，并弄清楚如何处理被拒绝的部分。

Once you have made the required changes, you can git addthe modified files and use git am --continueto tell git to commit the changes and move on to the next patch.

完成所需的更改后，您可以git add修改文件并使用它git am --continue来告诉 git 提交更改并继续下一个补丁。

What if there's nothing to do?

如果无事可做怎么办？

Since we don't have your code, I can't tell if this is the case, but sometimes, you wind up with one of the patches saying things that amount to, e.g., "fix the spelling of a word on line 42" when the spelling there was already fixed.

由于我们没有您的代码，我无法确定是否是这种情况，但有时，您会发现其中一个补丁说明了一些内容，例如“修复第 42 行单词的拼写”当那里的拼写已经固定时。

In this particular case, you, having looked at the patch and the current code, should say to yourself: "aha, thispatch should just be skipped entirely!" That's when you use the other advice git already printed:

在这种特殊情况下，您在查看了补丁和当前代码后，应该对自己说：“啊哈，这个补丁应该完全跳过！” 那是当你使用已经打印的其他建议 git 时：

If you prefer to skip this patch, run "git am --skip" instead.

If you prefer to skip this patch, run "git am --skip" instead.

If you run git am --skip, git will skip over that patch, so that if there were five patches in the mailbox, it will end up adding just four commits, instead of five (or three instead of five if you skip twice, and so on).

如果您运行git am --skip，git 将跳过该补丁，因此如果邮箱中有五个补丁，它最终只会添加四个提交，而不是五个（或者如果您跳过两次，则为三个而不是五个，依此类推）。

回答by wulfgarpro

git format-patchalso has the -Bflag.

git format-patch也有-B国旗。

The description in the man page leaves much to be desired, but in simple language it's the threshold format-patch will abide to before doing a total re-write of the file (by a single deletion of everything old, followed by a single insertion of everything new).

手册页中的描述还有很多不足之处，但用简单的语言来说，这是格式补丁在完全重写文件之前将遵守的阈值（通过一次删除所有旧内容，然后插入一次一切都是新的）。

This proved very useful for me when manual editing was too cumbersome, and the source was more authoritative than my destination.

当手动编辑太麻烦并且来源比我的目的地更权威时，这对我来说非常有用。

An example:

一个例子：

git format-patch -B10% --stdout my_tag_name > big_patch.patch
git am -3 -i < big_patch.patch

回答by Pini Cheyni

I had this error, was able to overcome it by using : patch -p1 < example.patch

我有这个错误，能够通过使用来克服它： patch -p1 < example.patch

I took it from here: https://www.drupal.org/node/1129120

我从这里拿的：https: //www.drupal.org/node/1129120

回答by Sandeep K V

Had several modules complain about patch does not apply. One thing I was missing out was that the branches had become stale. After the git merge mastergenerated the patch files using git diff master BRANCH > file.patch. Going to the vanilla branch was able to apply the patch with git apply file.patch

有几个模块抱怨补丁不适用。我错过的一件事是树枝已经过时了。之后，git merge master利用产生的补丁文件git diff master BRANCH > file.patch。转到香草分支能够应用补丁git apply file.patch

回答by Mritunjay Kumar Dubey

I faced same error. I reverted the commit version while creating patch. it worked as earlier patch was in reverse way.

我遇到了同样的错误。我在创建补丁时恢复了提交版本。它的工作原理与早期补丁相反。

[mrdubey@SNF]$ git log 65f1d63 commit 65f1d6396315853f2b7070e0e6d99b116ba2b018 Author: Dubey Mritunjaykumar

[mrdubey@SNF]$ git log 65f1d63 commit 65f1d6396315853f2b7070e0e6d99b116ba2b018 作者：Dubey Mritunjaykumar

Date: Tue Jan 22 12:10:50 2019 +0530

日期：2019 年 1 月 22 日星期二 12:10:50 +0530

commit e377ab50081e3a8515a75a3f757d7c5c98a975c6 Author: Dubey Mritunjaykumar Date: Mon Jan 21 23:05:48 2019 +0530

提交 e377ab50081e3a8515a75a3f757d7c5c98a975c6 作者：Dubey Mritunjaykumar 日期：2019 年 1 月 21 日星期一 23:05:48 +0530

Earlier commad used: git diff new_commit_id..prev_commit_id > 1 diff

之前使用的命令： git diff new_commit_id..prev_commit_id > 1 diff

Got error: patch failed: filename:40

得到错误：补丁失败：文件名：40

working one: git diff prev_commit_id..latest_commit_id > 1.diff

工作一： git diff prev_commit_id..latest_commit_id > 1.diff