比较Git中rebase的差异

Question

假设我只是衍合分支foo上master,有冲突的.我想foo通过引入额外的更改或丢失更改(除了适合冲突解决的更改),确保我不会在冲突解决期间意外损坏内容.我这样做是通过:

diff -u <(git diff `git merge-base master foo@{1}` foo@{1}) \
        <(git diff `git merge-base master foo    ` foo    )

(更新:或我刚刚提醒的等效...语法git-diff:)

diff -u <(git diff master...foo@{1}) <(git diff master...foo) | mate

这向我展示了master..foo被认为是补丁的所有变化,这正是我想要检查的最小化.但是,调用很复杂,输出的解释并不完全简单.

有没有更好的方法来完成这项任务 - 提供相同的信息,但有更好的方法或格式 - 或者我应该采取上述内容并将其包装在脚本中？

Answer 1

我们真正希望展示的是组合差异的冲突,就像我们已经完成合并以从(a)到(b),其中(a)以前基于(上游 - 旧)和(b)现在是基于(上游 - 新).

我们不想只是一个直的差异.

相反,我们基本上可以进行合并,但强制生成的树为$ b ^ {tree},我们已经知道这是我们想要的正确"结束"点.

或多或少,让我们假设我们有

newcommit -> the new version of the series
oldcommit -> the old version of the series
upstream -> the (new) version of the base of the series

我们可以通过生成合并

git commit-tree newcommit^{tree} -p oldcommit -p upstream -m "message"

然后用"git show"显示结果,这将生成一个组合的diff格式,它将所有必要的位显示为冲突解决方案,自动忽略实际上不是解决冲突的一部分的更改.

这甚至适用于只是ammending的变化,以及,你可以做一些更多的工作,以确保产生的合并提交有确切的作者和提交时间戳,以使得它在多次调用一致(因为我们都存储一个松散的裁判到对象数据库).

不幸的是,我还没有弄清楚如何在不实际生成树的情况下以相同的方式获得"git diff".我不确定我们必须通过哪些论点来达到这一点.

Answer 2

甚至比 更好interdiff，现在使用 Git 2.19（2018 年第 3 季度），您拥有git range-diff.
参见“ Git diff - 两个不相交的修订范围”

该git range-diff文档包括以下示例：

当 rebase 需要解决合并冲突时，使用以下命令直接比较 rebase 引入的更改：

$ git range-diff @{u} @{1} @

的典型输出git range-diff如下所示：

------------
-:  ------- > 1:  0ddba11 Prepare for the inevitable!
1:  c0debee = 2:  cab005e Add a helpful message at the start
2:  f00dbal ! 3:  decafe1 Describe a bug
    @@ -1,3 +1,3 @@
     Author: A U Thor <author@example.com>

    -TODO: Describe a bug
    +Describe a bug
    @@ -324,5 +324,6
      This is expected.

    -+What is unexpected is that it will also crash.
    ++Unexpectedly, it also crashes. This is a bug, and the jury is
    ++still out there how to fix it best. See ticket #314 for details.

    Contact
3:  bedead < -:  ------- TO-UNDO
------------

在此示例中，有 3 个旧提交和 3 个新提交，其中开发人员：

• 删除了第三个，
• 在前两个之前添加了一个新的，并且
• 修改了第二次提交的提交消息及其差异。

当输出到终端时，默认情况下它是彩色编码的，就像常规git diff的输出一样。另外，第一行（添加一个commit）是绿色的，最后一行（删除一个commit）是红色的，第二行（有完美匹配的）是黄色的，就像git show输出的commit header一样，第三行是颜色旧的提交是红色的，新的是绿色的，其余的像git show的提交标头。

使用 Git 2.20，新的（范围）差异可以更好地支持颜色

见提交2543a64，提交8d5ccb5，提交7648b79（2018年8月17日），以及提交4441067，提交f103a6f，提交29ef759，提交017ac45，提交9d1e1​​6b，提交84120cc，提交c5e64ca，提交991eb4f（2018年8月14日）由斯蒂芬贝勒（stefanbeller）。
^{（由Junio C gitsterHamano合并-- --在commit 30035d1，2018 年 9 月 17 日）}

range-diff: 缩进特殊行作为上下文

范围-DIFF着色是有点模糊，当涉及到一个diff的特殊线路，如表明新和旧文件以+++和---，因为它会皮卡的第一个字符并把它解释为它的颜色，这似乎恼人的，因为在常规的diff ，这些线通过 加粗 DIFF_METAINFO。

通过用空格缩进这些行，它们将被视为更有用的上下文，例如范围差异系列本身：

git range-diff pr-1/dscho/branch-diff-v3...pr-1/dscho/branch-diff-v4

（来自存储库github.com/gitgitgadget/git）

[...]
    + diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt
    + new file mode 100644
    + --- /dev/null
    + +++ b/Documentation/git-range-diff.txt
    +@@
    ++git-range-diff(1)
[...]
    +
      diff --git a/Makefile b/Makefile
      --- a/Makefile
      +++ b/Makefile
[...]

介绍手册页新文件的第一行将带有“ +”符号，其余行将是粗体。

后面指示更改的Makefile行将被视为外部和内部差异中的上下文，以便这些行保持常规颜色。

Answer 3

master 和 rebased foo 之间的区别：

git diff master..foo

与

分支 master 后 pre-rebase foo 的差异（注意三个点）：

git diff master...foo@{1}

？