我想使用git diff命令精确选择一些不相交的提交。
这是一个例子。提交在一个分支树上，从A（最旧的提交）开始，以Z（最近的提交）结束：
A
|
B
|
C
|
D
|
...
|
Y
|
Z
我想选择两个提交范围，B-D和O-Q（包含），并将它们与git diff一起使用。这可以通过两个命令来完成：
git diff B^..D
git diff O^..Q
是否可以仅使用一个git diff命令来执行此操作，以便只有一个输出？想象一下O回复D，不要单独描述O和D是有帮助的。
答案 0 :(得分：0)
使用new git range-diff command的Git 2.19（三年后的2018年第三季度）应该可以实现。
git range-diff B..D O..Q
这受trast/tbdiff，Thomas Rast和Thomas Gummerer的启发。
请参见commit a7be92a，commit 2752679，commit d1f87a2，commit 7190a67，commit ba931ed，commit 0b91faa，commit 31cf61a，{{3} }，commit f7c3b4e，commit 7188260，commit faa1df8，commit 4eba1fe，commit eb0be38，commit 1cdde29，commit 5e242e6，commit a142f97， commit c8c5e43的commit 9dc46e0，commit d9c66f0，commit 348ae56（2018年8月13日）。
请参阅Johannes Schindelin (dscho)的commit 8884cf1（2018年8月13日）。
（由Thomas Rast (``)在Junio C Hamano -- gitster --中合并，2018年8月20日）
range-diff：显示补丁之间的差异就像
tbdiff一样，我们现在显示匹配补丁之间的差异。 这是“两个差异的差异” ，因此对于初学者来说可能有点令人生畏。另一种方法是显示一个中间差异，即假设差异，它是首先还原旧差异然后应用新差异的结果。
尤其是在频繁重新定基础时，通常无法实现interdiff， 但是：如果旧的差异不能反向应用（由于移动） 上游），根本无法推断出interdiff。
此提交使
range-diff在tbdiff方面更接近于功能奇偶校验。使
git range-diff受到尊重，例如color.diff.*设置，我们必须相应地调整git_branch_config()。注意：虽然
tbdiff接受--no-patches选项以抑制补丁之间的差异，但我们更喜欢-s（或--no-patch）选项，该选项会通过使用自动得到支持的diff_opt_parse()。最后要注意：要支持diff选项，我们必须调用
parse_options()使其保留未知选项，然后遍历那些选项并让diff_opt_parse()处理它们。在该循环之后，我们必须再次调用parse_options()，以确保没有剩余的未知选项。
并且：
range-diff：使用暗/粗体提示来改善双色模式来看差异比较是一件令人困惑的事情。 太容易了，很容易混淆
-/+标记是指“内部”差异还是“外部”差异，即+是否指示一行是由旧的还是新的添加的diff（或两者），或者新的diff是否执行某些操作 与以前的差异有所不同。为使普通开发人员更容易处理，我们引入了双色模式，该模式根据提交差异为行着色，即，由提交添加的行（无论是旧的，新的，或两者）都以绿色着色。 。 在非双色模式下，行将根据外部差异进行着色：如果旧提交添加了行，则其将变为红色（因为行添加仅出现在命令中指定的第一个提交范围内行，即“旧”提交，但不在第二个提交范围内，即“新”提交）。
但是，这种双色模式仍无法使事情变得足够清晰，因为我们正在查看两个级别的差异，并且我们仍然仅根据其中一个 选择一种颜色（外部差异标记的颜色当然会有所不同，但是特别是在深凹痕的情况下，很容易丢失外部diff标记的背景颜色。
因此，让我们为混合添加另一个维度。 仍然根据提交差异使用绿色/红色/普通色，但现在也使仅旧提交中的行变暗，并对行使用粗体 只是在新提交中。
那样，当我们查看修补程序系列的上一迭代中添加的行，而新的迭代添加了一个稍有不同的版本时，就更容易忘记了，例如：变灰，则该补丁的当前版本将为粗体。
至少该开发人员以这种方式读取距离差异要容易得多。