git - git:通过提交查看对特定文件的更改

Question

我想在第147行查看对this文件所做的更改。因此，我逐行查询了文件的提交方式:

git blame include/svl/itemset.hxx

这是git blame的修剪输出:

4b3a535ae3 include/svl/itemset.hxx         (Michael Stahl      2015-04-08 15:02:47 +0200 145)     SfxItemPool*                GetPool() const { return m_pPool; }
4b3a535ae3 include/svl/itemset.hxx         (Michael Stahl      2015-04-08 15:02:47 +0200 146)     const sal_uInt16*           GetRanges() const { return m_pWhichRanges;
 }
d210c6ccc3 svl/inc/svl/itemset.hxx         (Xiaofei Zhang      2010-07-29 10:56:19 +0800 147)     void                        SetRanges( const sal_uInt16 *pRanges );
d210c6ccc3 svl/inc/svl/itemset.hxx         (Xiaofei Zhang      2010-07-29 10:56:19 +0800 148)     void                        MergeRange( sal_uInt16 nFrom, sal_uInt16 nTo );
4b3a535ae3 include/svl/itemset.hxx         (Michael Stahl      2015-04-08 15:02:47 +0200 149)     const SfxItemSet*           GetParent() const { return m_pParent; }

现在，我想看看使用SHA d210c6ccc3对这些行进行了哪些更改。基本上，我想查看此提交对文件所做的更改。所以我做了 :

`git show d210c6ccc3 include/svl/itemset.hxx`

但这似乎并没有给我正确的输出，实际上它什么也没输出。谁能建议我可能会缺少什么？或者，也许还有其他更好的方法来了解所选提交对文件进行了哪些更改？

Answer 1

eftshift0's answer是正确的(我对此表示赞同)。不过，这就是原因-以及这里可能出错的另一件事。

在大多数情况下，git show commit -- path是正确的，并且会向您显示:

指定提交的日志消息，

该特定文件的补丁程序，通过将该提交与其父文件进行比较而生成。

该补丁将与 git diff commit^1 commit -- path产生的补丁相同。 (请注意，此处的 ^1后缀是文字文本，而 commit部分是您要替换的哈希ID。后缀语法的意思是“查找第一个父对象”。您可以将此后缀添加到大多数提交选择器中，尽管不能添加到使用某些特定选择器的选择器中搜索模式。请参见 the gitrevisions documentation。)

有两个重要的异常(exception)。其中只有一种适用于此，因为 git blame通常不归咎于合并，它会尝试跟踪馈入合并的更改源。我还是要提一下，因为 git show在合并时的行为很有趣。 :-)

如果您查看带有 git show的合并提交，则默认情况下将看到组合的差异(“所有父项”与合并提交的内容)。在这种情况下，您可能希望直接回退到 git diff，以便可以指定要比较的父级( ^1， ^2，如果这是一个章鱼合并，甚至更多)。原因是合并的差异有意忽略任何与父提交中的版本相匹配的文件:这意味着从此刻起存储库中的任何内容都来自两个中的一个(如果N> 2，则为N)合并”。

使用 git blame，您正在寻找“谁改变了什么”。进行合并的人通常不是进行更改的人，因此，您应继续“在合并之后”查找真正更改它的人。

第二个异常(exception)是在这里给您造成问题的一个异常(exception)，实际上是在开发过程中重命名文件时 git blame工作方式的一种情况。

当 git blame分析文件的更改时，例如 include/svl/itemset.hxx，它一次从您指定的提交开始一次回退一个提交。如果您没有选择自己的起点，则从 HEAD(即当前提交)开始。然后，它查看父提交(例如，就像通过 git show一样)。例如，如果当前提交 922e935c8812是普通提交，并且其父级是 22c6554c98e2，则它将提交 922e935c8812与 22c6554c98e2进行比较。如果 22c6554c98e2具有相同名称的文件，则可能是相同的文件……但是，如果没有，Git会尝试找出 22c6554c98e2中的哪个文件与 include/svl/itemset.hxx是相同的文件。

在这种情况下，确切的事情发生在commit b9337e22ce1d上。提交 include/svl/itemset.hxx中有一个名为 b9337e22ce1d的文件，但是在提交 b9337e22ce1d^或 f4e1642a1761中，该文件名为 svl/inc/svl/itemset.hxx。当从commit b9337e22ce1d后退到commit f4e1642a1761时，Git会检测到此重命名，然后 git blame随身携带新名称，从commit f4e1642a1761提交到 d210c6ccc3。

但是，当您运行 git show d210c6ccc3时，Git会直接跳转到 d210c6ccc3(及其父 7f0993d43019)。它不再知道 include/svl/itemset.hxx中名为 HEAD的文件在 svl/inc/svl/itemset.hxx中名为 d210c6ccc3。因此，您必须发现它，并将更早的名称传递给Git。

您可能想知道如何找到它。答案是使用 git log --follow。 --follow的 git log代码不是很好，1但它与 git blame使用的代码相同，因此至少会产生相同的答案。这是我所做的:

$ git log --oneline --follow --name-status include/svl/itemset.hxx
00aa9f622c29 Revert "used std::map in SfxItemSet"
M       include/svl/itemset.hxx
afaa10da2572 make SfxItemSet with SAL_WARN_UNUSED
M       include/svl/itemset.hxx
[snip]
a7724966ab4f Bin comments that claim to say why some header is included
M       include/svl/itemset.hxx
b9337e22ce1d execute move of global headers
R100    svl/inc/svl/itemset.hxx include/svl/itemset.hxx

还有更早的第二次重命名。这是仅查找重命名的另一种较短的方法:

$ git log --oneline --follow --diff-filter=R --name-status include/svl/itemset.hxx
b9337e22ce1d execute move of global headers
R100    svl/inc/svl/itemset.hxx include/svl/itemset.hxx
e6b4345c7f40 #i103496#: split svtools in two libs, depending on whether the code needs vcl or not
R100    svtools/inc/svtools/itemset.hxx svl/inc/svl/itemset.hxx

如果 d210c6ccc3在 e6b4345c7f40之前，则必须使用偶数更早的路径名，但是commit d210c6ccc3是 e6b4345c7f40的后代，而不是祖先。

1当合并时发生更改时，从根本上说，这确实需要同时跟踪两个(或所有)输入提交。但是，Git无法(当前？)能够执行此操作: git log --follow和 git blame实际上仅遍历文件“最终来源”的最终父版本。也就是说，如果我们查看一个包含合并文件 M的典型合并提交 F，则有两个输入 M^1:F和 M^2:F，一个输出 M:F。如果 M:F与 M^1:F相同，则应完全忽略 M^2:F: M:F的所有内容都是提供 M^1:F的人的内容。如果 M:F与 M^2:F相同，则应完全忽略 M^1:F: M:F的所有内容都是提供 M^2:F的人的内容。

请注意，此操作一次仅适用于一个文件，即使如此，也仅在文件与两个输入之一完全匹配时才适用。否则，我们应该查看组合的差异，以了解如何从两个输入中修改文件。这是组合差异和历史简化的背后逻辑。但是在极少数情况下，它过于简化，因此有时会出错。