git log --cherry-pick --right-only --no-merges 会忽略分支之间正确挑选的所有提交吗？
Will git log --cherry-pick --right-only --no-merges ignore all commits correctly cherry-picked between branches?
我在一个大型软件团队工作，每月发布大量版本。我们在一个分支上工作以发布模型（见图表）。
这种模式解决了很多问题，但也有一些风险需要管理。当我将分支 1.1 发布到生产环境时，我需要检查 1.0 中的所有提交是否都在 1.1 中。
我可以使用以下命令执行此操作：
git log --cherry-pick --right-only --pretty="%h %ce %B" --no-merges release/1.1/master...release/1.0/master > missingcommits.log
然后我将此列表通过电子邮件发送给每个相关的开发人员，并请他们进行仔细的第二次检查。
这工作得很好，但我担心它会出现一些误报。
当然，如果您在两个不同的分支中签入了具有两次不同提交的相同代码，那么这将与此扫描发生冲突。
理论上，如果您从 1.0 到 1.1 精心挑选了您的提交 - 那么它不应该出现在此扫描中（即相同的提交在两个分支中）。
现在我的代码可以正常工作了。即在一个分支中的代码，我挑选穿过，然后它不会出现在这次扫描中。所以我认为它应该有效。
当我将电子邮件发送给开发人员 'missing commits in the new release branch' 时，我得到的是一些开发人员回信给我说：
No I definitely did a cherry pick to move my code over.
现在这可能是
(a) 防御行为，或
(b) 一个错误的选择，
(c) 我对git的误解，或者
(d) 这个过程确实存在问题。
我的问题是：git log --cherry-pick --right-only --no-merges 会忽略分支之间正确挑选的所有提交吗？
有两种可能的"errors"：
- 在您不希望列出时列出的提交（借用医学术语，误报）；和
- 在您确实希望列出它们时未列出（假阴性）。
存在一个单一的基础机制，这意味着两者都可能发生。然而，特别危险的情况——提交没有在应该列出的时候列出，即漏报——是非常罕见的。
要了解发生了什么，请先通读 git patch-id documentation。请注意，每个提交都有其自己唯一的哈希 ID，但给定两个 不同的 提交具有足够相似的 git diff 或 git show 输出，比较两个提交中的每一个它的父级，这两个不同的提交将具有 相同的 补丁 ID。换句话说，补丁 ID 是 尝试 来识别精心挑选的提交。
这种尝试并不完美。正如文档所说，补丁 ID 本质上是 diff 的校验和，其中行号和 diff 主体中的任何空白都被适当地剥离。如果有人 cherry-pick 一个提交并且它顺利进行，那么新的提交和原来的提交肯定会有相同的补丁 ID。但是如果有一些问题——如果提交需要一些手动冲突解决——新的提交可能会有一个不同的补丁 ID。这给了你误报：当有人必须检查提交 是否存在 时有点浪费时间，它只是稍微改变了形式。
false negative 意味着错过了更改重要内容（可能是关闭块的位置）的提交。当 diff #1 说 "move a close brace from line A to line B" 而 diff #2 说 "move a different close brace from line C to line D" 时，就会发生这种情况。 patch-ID 去掉了行号，右大括号只是一个右大括号。两个差异之间的缩进也可能会发生变化，但这也被忽略了。所以事实是 diff #1 中的循环 #1 受到影响，diff #2 中完全不同的循环 #2 受到影响。从语义分析的角度来看，这两个补丁 应该 被认为是不同的——但是 git patch-id 没有进行这样的分析，认为它们是相同的。
这些可以发生。如果你有一个好的测试套件，很可能任何这样的假阴性导致错过 cherry-pick 都会在测试中失败，但这绝对不是 Git 可以保证的。
我在一个大型软件团队工作，每月发布大量版本。我们在一个分支上工作以发布模型（见图表）。
这种模式解决了很多问题，但也有一些风险需要管理。当我将分支 1.1 发布到生产环境时，我需要检查 1.0 中的所有提交是否都在 1.1 中。
我可以使用以下命令执行此操作：
git log --cherry-pick --right-only --pretty="%h %ce %B" --no-merges release/1.1/master...release/1.0/master > missingcommits.log
然后我将此列表通过电子邮件发送给每个相关的开发人员，并请他们进行仔细的第二次检查。
这工作得很好，但我担心它会出现一些误报。
当然，如果您在两个不同的分支中签入了具有两次不同提交的相同代码，那么这将与此扫描发生冲突。
理论上，如果您从 1.0 到 1.1 精心挑选了您的提交 - 那么它不应该出现在此扫描中（即相同的提交在两个分支中）。
现在我的代码可以正常工作了。即在一个分支中的代码，我挑选穿过，然后它不会出现在这次扫描中。所以我认为它应该有效。
当我将电子邮件发送给开发人员 'missing commits in the new release branch' 时，我得到的是一些开发人员回信给我说：
No I definitely did a cherry pick to move my code over.
现在这可能是
(a) 防御行为，或
(b) 一个错误的选择，
(c) 我对git的误解，或者
(d) 这个过程确实存在问题。
我的问题是：git log --cherry-pick --right-only --no-merges 会忽略分支之间正确挑选的所有提交吗？
有两种可能的"errors"：
- 在您不希望列出时列出的提交（借用医学术语，误报）；和
- 在您确实希望列出它们时未列出（假阴性）。
存在一个单一的基础机制，这意味着两者都可能发生。然而，特别危险的情况——提交没有在应该列出的时候列出，即漏报——是非常罕见的。
要了解发生了什么，请先通读 git patch-id documentation。请注意，每个提交都有其自己唯一的哈希 ID，但给定两个 不同的 提交具有足够相似的 git diff 或 git show 输出，比较两个提交中的每一个它的父级，这两个不同的提交将具有 相同的 补丁 ID。换句话说，补丁 ID 是 尝试 来识别精心挑选的提交。
这种尝试并不完美。正如文档所说，补丁 ID 本质上是 diff 的校验和，其中行号和 diff 主体中的任何空白都被适当地剥离。如果有人 cherry-pick 一个提交并且它顺利进行，那么新的提交和原来的提交肯定会有相同的补丁 ID。但是如果有一些问题——如果提交需要一些手动冲突解决——新的提交可能会有一个不同的补丁 ID。这给了你误报：当有人必须检查提交 是否存在 时有点浪费时间，它只是稍微改变了形式。
false negative 意味着错过了更改重要内容（可能是关闭块的位置）的提交。当 diff #1 说 "move a close brace from line A to line B" 而 diff #2 说 "move a different close brace from line C to line D" 时，就会发生这种情况。 patch-ID 去掉了行号，右大括号只是一个右大括号。两个差异之间的缩进也可能会发生变化，但这也被忽略了。所以事实是 diff #1 中的循环 #1 受到影响，diff #2 中完全不同的循环 #2 受到影响。从语义分析的角度来看，这两个补丁 应该 被认为是不同的——但是 git patch-id 没有进行这样的分析，认为它们是相同的。
这些可以发生。如果你有一个好的测试套件，很可能任何这样的假阴性导致错过 cherry-pick 都会在测试中失败，但这绝对不是 Git 可以保证的。