错误：提交为合并，但未给出-m选项

Question

当我执行 git cherry-pick 命令时，出现了这个错误，我该如何解决？

$ git cherry-pick  XXXXXXXXXXXXX                                                                                                                                          
error: commit XXXXXXXXXXXXX is a merge but no -m option was given.
fatal: cherry-pick failed
$ git cherry-pick
    -m, --mainline <n>    parent number
$ git cherry-pick -m 1234 XXXXXXXXXXXXX
$ error: commit XXXXXXXXXXXXX does not have parent 1234
fatal: cherry-pick failed

- Sato

---

如果您提供一个建议选项呢？ - 0andriy

合并的父编号从1开始，一直计数到最高的父编号。换句话说，父亲#1是第一个父亲，父亲#2是第二个父亲，父亲#3是第三个父亲，因此必须是章鱼合并，依此类推。你期望从父亲#1234得到什么？ - torek

http://stackoverflow.com/a/41095200/1615903 - 1615903

可能是git cherry-pick says "...38c74d is a merge but no -m option was given"的重复问题。 - beat

这个回答解决了你的问题吗？由于合并时没有使用-m选项，因此不允许git revert <hash>操作。 - Josh Correia

Answer 1

使用git revert还原合并（转出为坏的特性分支）时，我遇到了相同的错误。 -m 有点让人困惑。 它不是在寻找信息。 我认为它只是想知道您希望还原多远（要还原多少次提交）从给定的提交中。

大多数时候只需还原1次。 也就是说，您只想返回到合并之前的提交（我提供的提交哈希）。 因此解决方案是：

git revert -m 1 <git_hash_for_merge>

- robjwilkins

---

你希望回退的提交数量是你所引用的提交之前的第一个提交。这意味着我想要回到提供的提交哈希之前的第一个提交。 - robjwilkins

根据stackoverflow.com/questions/41095143，我认为你是对的，-m的值指定要回溯的提交数，但重要的是它是基于日志中出现的项目。 对于一些人来说可能很明显，但对我来说并不是。此外，似乎重要的是要理解它指定要跟随的历史记录的_line_。我猜只有某些值是有意义的。我认为1总是指定一条线，但其他行可能不在2或其他值上，对吧？这些东西有点超出了我的能力范围，但这些似乎是重要的细节。 - steve

Answer 2

我认为帮助/手册已经很清楚地解释了为什么需要 -m 参数，错误消息也很明确地指出需要它：

-m parent-number, --mainline parent-number 通常情况下，您无法挑选合并操作，因为您不知道哪一侧的合并应该被视为主干。此选项指定了主干的父编号（从 1 开始），并允许 cherry-pick 相对于指定的父节点重新播放更改。

- jbu

---

我不会说“非常清楚”，“cherry-pick”的意思是什么？“side of the merge”是什么意思？“mainline”是什么意思？“parent number”是什么？“replaying changes”的意思是什么？这里用了相当多的不太清楚的行话。除非你对git非常熟悉，否则我怀疑你是否了解这些术语。 - cglacet

像大多数 Git 命令一样，它非常不直观。如果你想撤销某个合并操作，却发现无法直接操作。首先你需要阅读一些难以理解的文档，但是它并没有帮助你解决问题。最后你只能复制粘贴一些随机命令，并祈祷它能够奏效。 - laurent

我该如何找到主线父级编号？ - retro_coder

为了增加这个帮助文档的清晰度，当它说“你不知道哪一侧的合并应该被视为主线”时，我实际上希望它更简单：如果我将分支A合并到主分支，并且然后我想在主分支上撤消合并提交，那么很明显我想回到在合并之前的主分支状态。我真的不明白为什么git成为版本控制系统的赢家... ¯_(ツ)_/¯ - Rafa

要进一步说明这个帮助有多么不清楚，当它说“你不知道合并的哪一边应该被视为主线”时，我实际上希望它更简单一些：如果我将分支A合并到主线，然后在主线上想要撤销合并提交，显然我希望回到合并之前的主线状态。我真的不明白为什么git成为版本控制系统的赢家... ¯_(ツ)_/¯ - undefined