由`git bisect`或`git log -S --all`找不到由merge提交的更改

Question

我修复了一个文件,并将其提交到我的git存储库.

一段时间后,我发现它已经退步了.我想知道在提交修复已经取出来,所以我想git bisect和git log --all -S TERM,在"期限"是由我的修补程序和出现无处可在项目中添加一个字符串.

我发现git bisect归咎于一个无关的提交,我发现git log --all -S TERM只列出了我添加TERM的提交,并没有列出任何提交已删除它,即使它不再在"master"的文件中.

经过一些手动搜索后,我发现两个分支之间存在合并提交.一个分支有我的修复,一个没有.合并作者选择了没有我修复的分支(奇怪,因为文件中没有冲突).

我的问题是:

• 为什么git bisect找不到合并更改？关于此限制,我在联机帮助页中没有看到任何内容.有没有不同的方法来使用它会在上面的场景中找到错误的合并？
• 为什么不git log --all -S TERM列出合并提交？该联机帮助页显示它列出了"引入或删除实例"的提交.合并提交不会删除我的字符串吗？有没有不同的方法来使用它会在上面的场景中找到错误的合并？
• 如果git bisect和git log -S是在上述情况下没用,什么是找到坏合并的有效途径？如果没有这些工具,我需要花很长时间才能找到问题的变化.

Answer 1

为什么不git log --all -S TERM列出合并提交？

您必须-m向其中添加选项：

git log -m --all -S TERM

为了理解为什么在这种情况下需要一个特殊的选项，我们首先看看它的操作git log -p必须包括列出的历史记录中的更改。正如您可以轻松检查的那样，默认情况下不会显示合并提交更改。原因是更改是两个修订版之间的差异，而对于合并提交，我们有三个（或更多）修订版。-m解决git log该问题的选项：

差异格式

...

-m

该标志使合并提交像常规提交一样显示完整的差异； 对于每个合并父级，都会生成一个单独的日志条目和差异。--first-parent一个例外是，当给出选项时，仅显示与第一个父级的差异；在这种情况下，输出表示合并给当前分支带来的更改。

然后，假设这git log -S就像通过处理返回的差异一样工作，git log -p您应该承认默认情况下合并提交将从结果中排除。然而，幸运的是，您可以将-S和-m选项组合起来git log，它会按预期工作。