Question

如果我收到使用git diff rev^ rev甚至git show -p rev之类的内容生成的补丁文件，我该如何发现正在进行哪些提交？

我不肯定这个用例在git中甚至是相关的，但注意到cvs / svn中包含的补丁头中的文件路径和/或修订号给我一个温暖的模糊，我收到的补丁，或者已创建，正在针对正确的源或版本进行区分。

具体来说，如果我们检查git diff标头：

diff --git a/lib/blueprint/semantic_class_names.rb b/lib/blueprint/semantic_class_names.rb
index 41bd496..c17af1d 100644
--- a/lib/blueprint/semantic_class_names.rb
+++ b/lib/blueprint/semantic_class_names.rb

我找不到有关此差异所涉及的提交的区别信息。有一个索引行，我只能假设它不是缩写的提交哈希，而是文件的差异部分的哈希。它肯定与相关的提交签名不匹配。

如果我分辨了几个文件，并决定用电子邮件修补程序去旧学校，那么我没办法快速仔细检查我发送了正确的文件/修订版，然后再发出我用的修补程序快速浏览标题？据我所知，由于分布式特性，修订版在git中并不像cvs / svn那样有意义，但我是唯一一个不介意至少看到标题中文件的缩写提交签名的人吗？ / p>

Answer 1

diff中提供的哈希实际上是blob的哈希值。

因此，您可以使用此问题中提供的方法找到包含blob的提交：Git: Which commit has this blob?

Answer 2

如果您使用git show <rev>，（或git show -p <rev>），则会获得一个包含提交标识符的修补程序，以及作者，日期和提交消息。

$ git show rel
commit 82bf5b5df1e0308939a6e91cf4c7d2dae8088d99
Author: Brian Campbell 
Date:   Thu Mar 5 14:00:54 2009 -0500

    Update another file

diff --git a/another b/another
index 2102854..4083e0c 100644
--- a/another
+++ b/another
@@ -1 +1,3 @@
 Yet another
+
+More lines
\ No newline at end of file

修补程序实用程序通常会在修补程序开头忽略额外的内容，因此整个输出应该可以用作修补程序。您还可以使用git format-patch来获取格式化为易于自动发送的内容，例如使用git send-email或git imap-send。

正如htanata指出的那样，你在diff头文件中看到的单个文件是blob标识符;虽然您可以使用它来查找它可能来自的修订，但这将是缓慢的，而不一定是正确的。如果你需要引用提交，最好留下提及修补程序提交的标题。

Answer 3

您可以非常轻松地选择在树中已知路径中引入特定blob id的提交。

e.g。将blob_path设置为修补程序影响的树中的路径，并将blob_sha1设置为修补程序中的缩写sha1（即修补程序中的diff行后面的“index”后面的内容）脚本将找到引入该文件版本的提交。

for h in $(git log --pretty=format:%H "$blob_path")
do
    test "$(git rev-parse "$h:$blob_path")" = "$(git rev-parse "$blob_sha1")" &&
        echo $h
done

对于cours，您可能需要最新的仍然具有该文件版本的提交，在这种情况下，您希望在git log --pretty=format:%H "$blob_path"之前显示在其前面的提交的父级。

我怎样才能发现差异由哪些提交组成？

3 个答案: