3

“git cherry”命令非常适合识别已在上游应用的提交，但是如何获得与匹配的下游提交对应的 1-for-1 的确切上游提交 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 已应用于源/测试（或至少与补丁等效的提交）。请注意此输出中这 3 个提交旁边的减号“-”：

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

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

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

4

1 回答 1

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”命令的底层。:-)

于 2020-09-14T19:20:49.017 回答