Git 2.19引入了一个新的命令git range-diff，它可以执行以下操作：
git-range-diff-比较两个提交范围（例如一个分支的两个版本）

git range-diff [--color=[<when>]] [--no-color] [<diff-options>] [--no-dual-color]
               [--creation-factor=<factor>]\
               ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )

描述

这个命令显示补丁系列的两个版本之间的差异，或者更一般地说，显示两个提交范围（忽略合并提交）。
为此，它首先从两个提交范围中找到相互对应的提交对。当两个提交的补丁之间的差异（即作者信息，提交信息和提交差异）与补丁的大小相比相当小时，这两个提交就被认为是对应的。
最后，匹配提交的列表按照第二个提交范围的顺序显示，不匹配的提交会在所有祖先提交显示之后插入。
因此，在您的情况下：

git range-diff base old_commits new_commits

会自动匹配old_commits分支中的提交和new_commits分支中的提交，并显示每个提交之间的差异摘要。
或者，如果你只想得到每个分支上一次提交的修改，你可以运行：

git range-diff old_commits~..old_commits new_commits~..new_commits

从Git 2.31开始，你可以使用更简洁的形式来描述单次提交：

git range-diff old_commits^! new_commits^!

有关范围差的更多信息，请参见the official documentation。

也许是这样的：

git log -p -1 new_commits > patch.new
git log -p -1 old_commits > patch.old
diff patch.old patch.new

或者，对于简洁的一行程序（bash）：

diff <(git log -p -1 old_commits) <(git log -p -1 new_commits)

如果两个提交之间没有什么区别，那么比较删除的行和添加的行（即只比较以+或-开头的行）是有效的，它可以消除以@@开头的块边界或提交消息主体带来的噪音：

diff -u --ignore-matching-lines '^[^+-]' \
    <(git show 1d9e4ac) <(git show 7b8e5c9)

样本输出为：

--- /dev/fd/63  2015-02-13 13:27:08.612683558 +0100
+++ /dev/fd/62  2015-02-13 13:27:08.616683527 +0100
@@ -62,13 +57,24 @@
  }

 diff --git a/src/crush/CrushWrapper.h b/src/crush/CrushWrapper.h
-index 0113662..282cbeb 100644
+index 3b2e6e6..0a633a5 100644
 --- a/src/crush/CrushWrapper.h
 +++ b/src/crush/CrushWrapper.h
-@@ -874,6 +874,25 @@ public:
-     return false;
+@@ -863,6 +863,36 @@ public:
+     if (!crush) return -1;
+     return crush_find_rule(crush, ruleset, type, size);
    }
- 
++
++  bool ruleset_exists(int const ruleset) const {
++    for (size_t i = 0; i < crush->max_rules; ++i) {
++     if (crush->rules[i]->mask.ruleset == ruleset) {
++       return true;
++     }
++    }
++
++    return false;
++  }
++
 +  /**
 +   * Return the lowest numbered ruleset of type `type`
 +   *

你的两个补丁上的GNU相互差异失败了，因为它们没有直接的公共基础/父补丁。
而git range-diff产生一个diffs的外部diff（通常很难读取;关于先前提交中已消耗/合并的变更的不知道/不一致;不是一个适用的补丁格式），你可以通过合并一个提交的副本到另一个（最好是更新的）提交的父提交上来得到一个有效的可读性很好的interdiff。
在示例中比较<New commit 1>和<Old commit 1>很简单，因为它们已经有了一个直接公共父节点：

diff NC1 OC1

离共同基础更远的是，根据你的实际问题，我们得到的例子是这样的：

# move to the parent of NC3 - entering detached HEAD state
git checkout NC3~1
# merge-rebase the single patch <Old-commit-3> onto here
git cherry-pick OC3
# show the diff or reverse diff (or diff in gitk GUI)
git diff -R NC3
# back to feature_branch
git checkout feature_branch

当然，合并冲突可能会在这里出现--由于缺乏真实的的直接公共父项，这（必然）会暴露与“虚拟公共库”的一种相互差异不兼容的更改。
可以创建一个（临时的）标签或分支来保存这个重定基的 * 比较提交 *（或提交范围）--例如，用于与其他用户讨论和工作。否则，临时的未引用的悬空提交很快就会被自动回收。

也许这会给予你想要的东西，但是如果提交1-2-3是非常依赖的，它就会失败。

$ git checkout 'old commit 2'
$ git cherry-pick -n 'new commit 3'
$ git diff 'old commit 3'

$ git checkout 'new commit 2'
$ git cherry-pick -n 'old commit 3'
$ git diff 'new commit 3'