当运行“git cherry”命令时，如何获取“另一个”提交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”命令来添加一个额外的输出列（因为它肯定在内部知道映射关系），但我想问问互联网上是否有人知道在此之前有任何可能性。

- G. Sylvie Davies

Answer 1

我发布了这个问题后，这是针对git源代码中builtin/log.c的补丁，给了我想要的确切行为。

我想要的行为如下：

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”命令中，数据就在那里。 :-)

- G. Sylvie Davies

---

我以前也想在 git log --left-right --cherry-mark A...B 中实现类似的功能。在 git cherry 中，有一个更清晰的显示位置，比在 git log --left-right 中更好。 - torek

哦，亲爱的，如果你（@torek）也想要这个，那可能意味着它不存在。唉！祝我好运，让Git上游接受（这个完善版本的）补丁！ - G. Sylvie Davies