36

我一直在使用 git-format-patch 和 git-am 将更改从一个存储库应用到另一个存储库。文件结构是相同的，但是我应用的存储库中有一些更改导致大多数补丁失败了一些大块。但是大多数补丁程序都在行号中应用了一些模糊性。

据我所知，git-am apply这是一个非常严格的解释，所以完全拒绝所有这些补丁。

所以我的工作流程变成了

$ git am ../the-patch.patch
# Fails because the patch doesn't apply cleanly
$ patch -p1 < ../the-patch.patch
# Applies most of the hunks, leaves .rej files for the ones that conflict
# Fix the conflicting hunks manually
$ git am --continue

如果我不必运行命令行补丁并且可以将其作为 am 命令的一部分发生，那就太好了。

如果有任何冲突，使用该--reject标志运行似乎会创建一个包含文件中所有块的 .rej 文件，这不是我想要的。

使用--3way标志运行失败

fatal: sha1 information is lacking or useless (the-file.java).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

我认为这是因为基于此的更改集不在我要合并的存储库中。

有没有办法git-am apply像原始补丁命令一样使用模糊匹配制作补丁，并且只创建包含失败的大块的 .rej 文件？

4

6 回答 6

2

您可以执行以下操作：

git am /path/to/some.patch
patch -p1 < /path/to/some.patch
git add .
git am --continue

这将应用补丁并保留提交消息等。

于 2018-11-28T21:13:31.000 回答
2

怎么样：

git_apply-fuzzy() {
   if ! git am "$@"; then
      local patch="$(git rev-parse --show-toplevel)/.git/rebase-apply/patch"
      if [ -e "$patch" ] && patch --dry-run -p1 < "$patch"; then
          if patch -p1 < "$patch"; then
              sed -n -e '/^+++ b\//{s///;p}' "$patch" | xargs git add &&
              git am --continue &&
              return 0 ||
              patch -p1 -R < "$patch"
          fi
      fi
      git am --abort
      return 1
   fi
}
git_apply-fuzzy mypatch.patch

它尝试“git am”，如果失败，尝试补丁（如果发生任何奇怪的事情，则恢复）

于 2020-03-19T22:38:05.830 回答
2

如果我对您的理解正确，您尝试将代码形式 1 repo 合并到另一个 repo 并且您在代码的某些部分上失败了。然后您手动修复它，从现在开始您希望它被合并而没有任何错误。

在这种情况下，您应该使用git rerere

在使用相对长寿主题分支的工作流中，开发人员有时需要一遍又一遍地解决相同的冲突，直到主题分支完成（合并到“发布”分支，或者发送出去并接受上游）。

此命令通过在初始手动合并上记录冲突的自动合并结果和相应的手动解决结果并将先前记录的手动解决方案应用于其相应的自动合并结果来帮助开发人员完成此过程。

git config --global rerere.enabled true
于 2016-01-06T21:56:17.957 回答
1

有 --recount 参数，但仅适用于 git-apply 命令，因此理论上的顺序是：

git mailsplit ...   
git mailinfo ...
git apply --recount ...
git add ...
git commit ...
于 2018-06-04T12:12:04.767 回答
1

根据@Nick Desaulniers 上面链接到的线程，看起来使用-3选项 to git apply/am至少在某种程度上会起作用。

例如，这是我的输出，其中包含一个失败的补丁git apply：

$ git apply < patch_file.patch error: patch failed: file_being_patched.txt:489 error: file_being_patched.txt: patch does not apply $ git apply -3 < patch_file.patch error: patch failed: file_being_patched.txt:489 Falling back to three-way merge... Applied patch to 'file_being_patched.txt' cleanly.

遗憾的是它仍然给出了一个错误（更难在脚本中解析输出），并且它没有说明 fuzz 的级别是什么patch，因为 fuzz 级别通常是一个很好的指示补丁命令是否可能弄错了。

于 2017-06-22T12:29:17.450 回答
0

这具有功能请求的特征。要确定这一点，请加入 Git 邮件列表 (git@vger.kernel.org) 并阅读一段时间以了解文化。同时按照上面的建议通过准备之前/之后的文档来澄清你的想法。

当你觉得准备好了，然后在名单上介绍自己并简洁地解释你的想法。请务必解决您的提案的效果是否可以通过其他方式充分实现的问题。如果您收到鼓励的话，请跟进您的更详细的文档。收到您提案的反馈后，您可能决定继续提交功能请求错误，或者您可能会发现自己可以创建一个补丁以供考虑。

于 2015-07-20T20:29:23.473 回答