Git diff-两个不相交的修订范围 [英] Git diff - two disjoint revision ranges

问题描述

我想使用git diff命令精确选择一些不相交的提交.

I would like to select precisely some disjoint commits using the git diff command.

这里是一个例子.提交放在一分支树上，从A(最旧的提交)开始，到Z(最新的提交)结束:

Here is an example. The commits are disposed on a one-branch tree, starting with A (the oldest commit), and ending with Z (the most recent commit):

A 
|
B
|
C
|
D
|
...
|
Y
|
Z

我想选择两个提交范围，即B-D和O-Q(包括)，并将它们与git diff一起使用.这可以通过两个命令来完成:

I would like to select two ranges of commits, B-D and O-Q (included), and use them with git diff. This can be made with two commands:

git diff B^..D
git diff O^..Q

是否可以仅使用一个git diff命令来执行此操作，以便仅获得一个输出?试想一下，O还原了D，所以不要分别描述O和D是很有帮助的.

Is it possible to do it using only one git diff command, in order to have only one output? Just imagine that O reverts D, it is helpful not to have O and D described separately.

推荐答案

使用这是受Thomas Rast和Thomas Gummerer的 trast/tbdiff 的启发.

This is inspired by trast/tbdiff, by Thomas Rast and Thomas Gummerer.

请参见提交a7be92a ，提交d1f87a2 ，提交7190a67 ，提交0b91faa ，提交31cf61a ，提交7188260 ，提交faa1df8 ，，提交1cdde29 ，提交a142f97 ，提交9dc46e0 ，提交d9c66f0 ，提交8884cf1 (2018年8月13日)，作者是. ^(由 Junio C Hamano-gitster-在

See commit a7be92a, commit 2752679, commit d1f87a2, commit 7190a67, commit ba931ed, commit 0b91faa, commit 31cf61a, commit f7c3b4e, commit 7188260, commit faa1df8, commit 4eba1fe, commit eb0be38, commit 1cdde29, commit 5e242e6, commit a142f97, commit c8c5e43, commit 9dc46e0, commit d9c66f0, commit 348ae56 (13 Aug 2018) by Johannes Schindelin (dscho). See commit 8884cf1 (13 Aug 2018) by Thomas Rast (``). ^{(Merged by Junio C Hamano -- gitster -- in commit 81eab68, 20 Aug 2018)}

range-diff:显示补丁之间的差异

就像tbdiff一样，我们现在显示匹配补丁之间的差异. 这是两个差异的差异" ，因此对于初学者来说可能有点令人生畏.

range-diff: show the diff between patches

Just like tbdiff, we now show the diff between matching patches. This is a "diff of two diffs", so it can be a bit daunting to read for the beginner.

另一种选择是显示一个中间差异，即假设差异，它是首先还原旧差异然后应用新差异的结果.

An alternative would be to display an interdiff, i.e. the hypothetical diff which is the result of first reverting the old diff and then applying the new diff.

尤其是在频繁重新定标时，通常无法实现interdiff的功能， 但是:如果旧的差异不能反向应用(由于移动) 上游)，根本无法推断出interdiff.

Especially when rebasing frequently, an interdiff is often not feasible, though: if the old diff cannot be applied in reverse (due to a moving upstream), an interdiff can simply not be inferred.

此提交使range-diff就tbdiff而言更接近于功能奇偶校验.

This commit brings range-diff closer to feature parity with regard to tbdiff.

要尊重git range-diff，例如color.diff.*设置，我们必须相应地调整git_branch_config().

To make git range-diff respect e.g. color.diff.* settings, we have to adjust git_branch_config() accordingly.

注意:虽然tbdiff接受--no-patches选项以抑制补丁之间的差异，但我们更喜欢-s(或--no-patch)选项，该选项通过使用diff_opt_parse()会自动得到支持.

Note: while tbdiff accepts the --no-patches option to suppress these diffs between patches, we prefer the -s (or --no-patch) option that is automatically supported via our use of diff_opt_parse().

最后要注意:为了支持diff选项，我们必须调用parse_options()，使其保留未知选项，然后遍历那些选项并让diff_opt_parse()处理它们.在该循环之后，我们必须再次调用parse_options()，以确保没有剩余的未知选项.

And finally note: to support diff options, we have to call parse_options() such that it keeps unknown options, and then loop over those and let diff_opt_parse() handle them. After that loop, we have to call parse_options() again, to make sure that no unknown options are left.

---

并且:

---

And:

range-diff:使用暗/粗体提示改善双色模式

来看差异比较是一件令人困惑的事情. 很容易混淆-/+标记是指内部"差异还是外部"差异，即+指示是由旧差异还是新差异添加了一行(或两者都添加了) )，或者新的差异是否有作用 与以前的差异有所不同.

range-diff: use dim/bold cues to improve dual color mode

It is a confusing thing to look at a diff of diffs. All too easy is it to mix up whether the -/+ markers refer to the "inner" or the "outer" diff, i.e. whether a + indicates that a line was added by either the old or the new diff (or both), or whether the new diff does something different than the old diff.

为使普通开发人员更容易处理，我们引入了双色模式，该模式根据提交差异为行着色，即，由提交添加的行(无论是旧的，新的，或二者都用)涂成绿色. . 在非双色模式下，行将根据外部差异进行着色:如果旧提交添加了行，则其将变为红色(因为行添加仅存在于命令中指定的第一个提交范围中行，即旧"提交，但不在第二个提交范围内，即新"提交).

To make things easier to process for normal developers, we introduced the dual color mode which colors the lines according to the commit diff, i.e. lines that are added by a commit (whether old, new, or both) are colored in green. In non-dual color mode, the lines would be colored according to the outer diff: if the old commit added a line, it would be colored red (because that line addition is only present in the first commit range that was specified on the command-line, i.e. the "old" commit, but not in the second commit range, i.e. the "new" commit).

但是，这种双色模式仍无法使事情变得足够清晰，因为我们正在查看两个级别的差异，并且我们仍然只能根据其中一个 选择一种颜色(外部差异标记的颜色当然会有所不同，但是特别是在深凹痕的情况下，很容易丢失外部diff标记的背景颜色.

However, this dual color mode is still not making things clear enough, as we are looking at two levels of diffs, and we still only pick a color according to one of them (the outer diff marker is colored differently, of course, but in particular with deep indentation, it is easy to lose track of that outer diff marker's background color).

因此，让我们为混合添加另一个维度. 仍然根据提交差异使用绿色/红色/普通色，但现在也使仅旧提交中的行变暗，并为行使用粗体 只是在新提交中.

Therefore, let's add another dimension to the mix. Still use green/red/normal according to the commit diffs, but now also dim the lines that were only in the old commit, and use bold face for the lines that are only in the new commit.

那样，当我们查看修补程序系列的上一迭代中添加的行，而新的迭代添加了一个略有不同的版本时，就更容易忘记了，例如:变灰，则该补丁的当前版本将为粗体.

That way, it is much easier not to lose track of, say, when we are looking at a line that was added in the previous iteration of a patch series but the new iteration adds a slightly different version: the obsolete change will be dimmed, the current version of the patch will be bold.

至少该开发人员可以更轻松地以这种方式读取范围差异.

At least this developer has a much easier time reading the range-diffs that way.

这篇关于Git diff-两个不相交的修订范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！