git - 运行 "git cherry"时如何获取 *other* commit-id？

Question

“git cherry”命令非常适合识别已在上游应用的提交，但我如何才能获得与我匹配的下游提交一对一对应的准确上游提交 ID？

这是我的情况:

* 04876f4 (HEAD -> test-rebased) c
* 1e73b75 b
* 8ce948c a
* 8cc1e21 (origin/master) m
| * 4b8bc3e (origin/test) c
| * f207a10 b
| * 1c15641 a
|/  
* 0a943a2

“git cherry”命令非常适合注意到 8ce948c、1e73b75 和 04876f4 已经应用于 origin/test(或至少是补丁等效提交)。请注意此处输出中那 3 次提交旁边的减号“-”:

git cherry -v test HEAD
+ 8cc1e2105f387eeede67a87688b6bfae0cab42c6 m
- 8ce948ca1b54d551581f4574bda2c215cc96a351 a
- 1e73b75de891eab9314856558624e9b4c21bbb1f b
- 04876f4e615b2bb70b969e99de15ec78b1ea84f6 c

但它没有告诉我他们如何将一对一映射到我的本地提交(在我的“test-rebased”分支上)。有谁知道可以给我映射的任何 git 命令组合？注意:假设提交消息不稳定(即使它们在我这里的示例中)。它们可能会在我的本地分支中发生巨大变化(例如，我可能会执行“git commit --amend”来重写提交消息)。

可能做到这一点的唯一方法是修补“git cherry”命令以添加额外的输出列(因为它肯定知道引擎盖下的映射)，但我想我会问互联网是否有人知道在我冒险走那条路之前，这里有任何可能性。

Answer 1

一个快速附录(我发布了问题)- 这个针对 builtin/log.c 的补丁(来自 git 的源代码)给了我我想要的确切行为。

这是我想要的行为:

git cherry -v test HEAD
+ 8cc1e2105f387eeede67a87688b6bfae0cab42c6 - m
- 8ce948ca1b54d551581f4574bda2c215cc96a351 1c156417bff133e25664fe7047b5df6a81fbd2f7 a
- 1e73b75de891eab9314856558624e9b4c21bbb1f f207a10a5249f9e0fe74184f8b03c75bbf7488c5 b
- 04876f4e615b2bb70b969e99de15ec78b1ea84f6 4b8bc3eab7c625f298ca3bd031ba141b66240da4 c

这是补丁:

diff --git a/builtin/log.c b/builtin/log.c
index d104d5c688..a32f0bede7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -2153,17 +2153,19 @@ static const char * const cherry_usage[] = {
        NULL
 };
 
-static void print_commit(char sign, struct commit *commit, int verbose,
+static void print_commit(char sign, struct commit *commit, struct commit *other, int verbose,
                         int abbrev, FILE *file)
 {
        if (!verbose) {
-               fprintf(file, "%c %s\n", sign,
-                      find_unique_abbrev(&commit->object.oid, abbrev));
+               fprintf(file, "%c %s %s\n", sign,
+                      find_unique_abbrev(&commit->object.oid, abbrev),
+                      other ? find_unique_abbrev(&other->object.oid, abbrev) : "-");
        } else {
                struct strbuf buf = STRBUF_INIT;
                pp_commit_easy(CMIT_FMT_ONELINE, commit, &buf);
-               fprintf(file, "%c %s %s\n", sign,
+               fprintf(file, "%c %s %s %s\n", sign,
                       find_unique_abbrev(&commit->object.oid, abbrev),
+                      other ? find_unique_abbrev(&other->object.oid, abbrev) : "-",
                       buf.buf);
                strbuf_release(&buf);
        }
@@ -2238,12 +2240,17 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
        }
 
        while (list) {
+               struct patch_id *id;
+               struct commit *upstream_commit = NULL;
                char sign = '+';
 
                commit = list->item;
-               if (has_commit_patch_id(commit, &ids))
+               id = has_commit_patch_id(commit, &ids);
+               if (id) {
                        sign = '-';
-               print_commit(sign, commit, verbose, abbrev, revs.diffopt.file);
+                       upstream_commit = id->commit;
+               }
+               print_commit(sign, commit, upstream_commit, verbose, abbrev, revs.diffopt.file);
                list = list->next;
        }
 

如果有某种方法可以在不尝试将补丁程序接受到 git 项目中的情况下完成此操作，显然会更好，但我认为发布此内容可能有助于明确我正在寻找的内容。果然数据就在“git cherry”命令的幕后。 :-)