39

我正在尝试使用 git am -3“补丁路径”将一系列补丁从 1 个 git 存储库应用到另一个 git 存储库。我按顺序应用它们，从补丁 1-4 开始，它工作正常。

但是当我来到第 5 个补丁时，我收到错误消息“致命：sha1 信息缺失或无用”。我转到应用补丁的 git 存储库，我确实看到了文件“dev/afile”。所以我想知道为什么 git 抱怨“sha1 信息缺乏或无用（dev/afile.c）”，我该如何解决我的问题？

 $ git am -3 ~/Tmp/mypatches/0005-fifth.patch
Applying: rpmsg: Allow devices to use custom buffer allocator
fatal: sha1 information is lacking or useless (dev/afile.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 first patch
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

以及为什么它说“补丁在第一个补丁 0001 失败”，当我执行“git am -3 ~/Tmp/mypatches/0005-fifth.patch”时，它没有错误地完成。

谢谢你。

4

8 回答 8

15

只需执行以下操作即可解决此问题：

patch -p1 < example.patch
于 2018-03-28T14:28:50.737 回答
13

以 开头的补丁文件0001-无法干净应用 - 存在一些冲突。

Git 想通过查看此补丁所基于的提交来解决该冲突，但您的存储库中没有这些提交。

可能补丁是从具有从未共享的提交的分支创建的，或者您或提交者的分支已被重新设置。

可以毫无错误地应用补丁并不重要0005-。错误是关于0001-具体的。

于 2013-07-16T21:13:32.160 回答
12

我在尝试将补丁从一个存储库应用到一个具有不相关历史记录（同一个项目但具有重建的 git 历史记录）的存储库时遇到了这个问题。您收到消息的原因fatal: sha1 information is lacking or useless (dev/afile.c)是当 git 尝试进行 3 路合并时，它需要访问该文件的状态。这些文件由格式补丁输出中的哈希指向（例如）

diff --git a/dev/afile.c b/dev/afile.c
index ebbd50fc0b7..ef1ca87ead0 100644
--- a/dev/afile.c
+++ b/dev/afile.c

ebbd50fc0b7 和 ef1ca87ead0 指的是文件内容的哈希，而不是提交哈希。

如果你试试：

git cat-file blob <hash from patch>

Git 将报告：

fatal: Not a valid object name <hash from patch>

Git 找不到它们，因为这些版本的文件在您的本地存储库中不可用（因此出现了 message Repository lacks necessary blobs to fall back on 3-way merge.）。您可以通过以下方式使这些对象在本地存储库中可用：

git remote add old_repo <url>
git fetch old_repo

现在，当您运行时：

git cat-file blob <hash from patch>

您应该得到该文件的内容。现在git am再次尝试您的命令，它应该能够进行 3 路合并。

于 2019-01-30T11:03:55.053 回答
10

您在项目中使用子模块吗？

git 1.7.12 到 1.8.1.2 中存在一个错误，其中更新的子模块会导致变基（或补丁）失败并显示错误消息：

致命：sha1 信息缺失或无用

如果应用，则将提交留空。

更多信息在这里。

更新 git 到 1.8.4 版本解决了这个问题

于 2013-09-25T13:00:54.860 回答
3

当我尝试在错误的分支上创建补丁时遇到了这个问题。

我认为“git format-patch ...”能够确定我想要什么，因为您可以在 format-patch 调用中指定主分支和要修补的分支。我意识到这是错误的，因为它提到的提交是我正在修补的站点上不存在的分支的一部分。

长话短说，当你创建补丁时，确保你在你想要补丁的分支上。

于 2016-02-26T19:04:40.283 回答
0

我遇到了类似的冲突，对我有用的第 n 个解决方案是：

  1. 显示当前补丁无法应用
  2. 找到原始提交哈希/校验和/id
  3. 转到我要从中复制补丁的存储库
  4. 在我申请失败之前检查提交
  5. 按原样复制受影响的文件
  6. 添加现在更改的文件
  7. 继续申请流程：
new_repo> git am -3 /tmp/bunchopatches/*
# 10: ERROR happens
new_repo> git am --show-current-path | head -n 1
# From fe89d2a53ccf30d068fdd5596a325f06b74ec4af Mon Sep 17 00:00:00 2001
orig_repo> git checkout fe89d2a53ccf30d068fdd5596a325f06b74ec4af^
orig_repo> cp aff/ected/files/* /new_repo/aff/ected/files/
new_repo> git add aff/ected/files/*
new_repo> git am --continue
# rince and repeat (goto 10)

（如果您在单独的窗口中执行 orig_repo> 命令，这实际上可能是一个相当快的过程，只需以这种方式应用 80 个补丁和大约 10 个间距冲突=

于 2020-10-22T00:57:58.153 回答
0

如果您确定可以应用补丁而不用担心更改的周围上下文，您可以告诉使用此命令忽略任何上下文git am -C0 your.patch

从文档：

-C<n>
确保每次更改前后至少有几行周围的上下文匹配。当周围上下文的行数较少时，它们都必须匹配。默认情况下，不会忽略任何上下文。

于 2021-07-14T21:00:59.973 回答
0

也许这是一个 git 的错误。最后我改用cherry-pick来解决冲突。

于 2021-08-31T03:20:40.323 回答