git-cherry 似乎不适用于无序合并

发布于 2024-10-25 06:00:52 字数 588 浏览 4 评论 0原文

我尝试使用 gitcherry-pick 来合并来自 master 的一些提交，然后使用 git-cherry 来确定当前合并的提交。当我按照 master 上的顺序合并它时，它工作得很好，但是当我跳过合并其中一个提交时，它不会显示下一个合并的内容。下面的示例：

$ git branch
* branch
  master
$ git log --oneline
46aad17 comment4
56e43b0 comment3
26370b3 comment2
6192fa4 comment1

$ git cherry -v branch master
- 5c5e979707cd6a77ef3ae79627cdd211cad86a28 comment3
- ee0386c78d9e6d21dce7a8bac8e40beef73fb993 comment4
+ 9495c94ece440d9a05c3218f88d1b72a7fd67664 unmerged # this wasn't merged
+ 235b0822f08f351264071e7b2500caa9af997fb8 comment2

问题是为什么 comment2 显示为未合并，而在日志中显示为已合并？

原文

I tried to use git cherry-pick for merging some commits from master and then git-cherry to determine what commits currently merged. It works fine while I merge it in the order it's on master, but when I skip merging one of the commits it doesn't show me the next merged.
Example below:

$ git branch
* branch
  master
$ git log --oneline
46aad17 comment4
56e43b0 comment3
26370b3 comment2
6192fa4 comment1

$ git cherry -v branch master
- 5c5e979707cd6a77ef3ae79627cdd211cad86a28 comment3
- ee0386c78d9e6d21dce7a8bac8e40beef73fb993 comment4
+ 9495c94ece440d9a05c3218f88d1b72a7fd67664 unmerged # this wasn't merged
+ 235b0822f08f351264071e7b2500caa9af997fb8 comment2

The question is why comment2 shown as unmerged while it's shown merged in log?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

落墨 2024-11-01 06:00:52

作为初步说明，将这些描述为合并有点令人困惑 - 它们只是精选的内容，即通过将另一个提交引入的补丁应用到新父级来创建的提交。

gitcherry 查看提交引入的补丁，并测试上游分支中是否已经引入了类似的补丁。如 gitcherry 手册页中所述，它根据两个补丁是否具有相同的 “补丁ID”，描述为：

“补丁 ID”只不过是与补丁关联的 diff 的 SHA1，忽略空格和行号。因此，它“相当稳定”，但同时也相当独特，即，具有相同“补丁 ID”的两个补丁几乎可以保证是相同的东西。
IOW，您可以使用这个东西来查找可能的重复提交。

因此，我怀疑如果与 comment2 关联的提交未被检测为已应用，那是因为补丁 ID 不同。例如，这可能是因为您在挑选与 comment2 关联的提交时必须解决冲突。这很可能意味着提交引入的补丁最终会有所不同。您可以通过比较这两个命令的输出来查看这是否正确：

git show 26370b3
git show 235b082

Just as a preliminary note, it's a bit confusing to describe these as merges - they're just cherry-picks, i.e. commits created by applying the patch introduced by another commit onto a new parent.

git cherry looks at the patch which a commit introduces, and tests to see if there is already a similar patch that has been introduced in the upstream branch. As documented in the git cherry man page, it decides whether two patches are the same based on whether they have the same "patch ID", which is described as:

A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with whitespace and line numbers ignored. As such, it’s "reasonably stable", but at the same time also reasonably unique, i.e., two patches that have the same "patch ID" are almost guaranteed to be the same thing.
IOW, you can use this thing to look for likely duplicate commits.

So, I suspect that if the commit associated with comment2 isn't detected as having already been applied that's because the patch IDs are different. That might, for example, be because you had to resolve a conflict when cherry-picking the commit associated with comment2. That might well mean the patches that the commits introduced ended up being different. You can see if that is right by comparing the output of these two commands: