手册页git-log（1）说：
-r
显示递归差异。
因此，我们可以用另一种方式提出这个问题：
在这种情况下，“递归差异”是什么意思。
从@phd 获得此答案后，我做了一些针对指示方向的测试：
如果我在当前版本的Git源存储库（最近从https://github.com/git/git.git克隆）中执行以下命令并签出master（当前指向commit 6a6c0f1），它们将给出相同的输出：
git log --name-only -m
git log --name-only -m -r
（对于这个工作，人们可能不得不增加diff.renameLimit对周围3150）。我试图与Git的版本2.10.2和2.17.1获得平等的结果。
另外，命令
git log --name-only -m master~..master
输出
commit 6a6c0f10a70a6eb101c213b09ae82a9cad252743
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu May 9 00:37:54 2019 +0900
The eighth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/RelNotes/2.22.0.txt
从最后一行可以看到，即使没有，该命令也会进入子目录-r。
当 Git 合并由于冲突或用户使用选项请求而停止时--no-commit，合并被认为仍在进行中，这通过文件的存在来指示$GIT_DIR/MERGE_HEAD。
当提交合并结果或中止合并时，此状态通常结束。在后一种情况下，合并引入的更改将被回滚。
有没有什么方法可以完成“合并正在进行”状态而不生成提交并且不会丢失合并中的更改？让我们假设所有可能的冲突都已解决。1这类似于为--quit挑选、恢复和变基提供的选项。
一个明显的方法是git reset --soft，但是当合并正在进行时，这个错误就会出现。
对于这个问题，我没有任何具体的用例，但我想知道 Git UI 在这一点上的完整性。
1从 torek 非常详细的回答中可以看出，未解决的冲突意味着索引槽 1 到 3 中的条目，这些条目仅在正在进行的合并期间才有意义，严格来说甚至构成一个。这意味着：只要存在未解决的冲突，合并就会持续进行。因此，为了使这个问题反映一个适定的问题，它必须限于所有可能的冲突都得到解决的情况。
手册页git-rebase（1）说：
-m
--merge
使用合并策略进行基准调整。[...]
但是当然，如果不使用该--merge选项，也可能会遇到“合并冲突” 。因此，在那种情况下，也必须有任何“合并策略”来处理这些冲突。
有什么区别使得可以--merge选择重新基准。
这似乎是一个相当基本的东西：对于A rebase --merge，Git将其工作文件存储在一个名为的文件夹中$GIT_DIR/rebase-merge（与交互式rebase一样）。如果--merge未使用该选项（并且变基是非交互式的），则该文件夹名为$GIT_DIR/rebase-apply。