git commit integrity

我试着搜索git commit由什么组成，以及哪些部分参与了commit的sha哈希。但是，可能我在问错话，我什么都没发现。git commit integrity

我想知道什么提交包含。我读社区书了一下，有以下图片：

enter image description here

但是我认为犯有比图中显示更多的领域。

现在的主要问题是：哪些字段参与了commit sha hash？我在问，因为我在不同的仓库提交了两个具有相同散列哈希的提交，但具有不同的父提交。在此之前，我认为如果两个提交相同并且具有相同的父提交，则两个提交可能具有相同的哈希散列。所以我有点困惑。

我有两个本地存储库（git1，git2）一个是其他的克隆。

GIT1

commit 4f438f9579939312689eb67e5fb7957d87cfa036 <-- this commit 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:00:31 2012 +0300 

    stuff after change 

commit e91e833158bb44f54f418cc5c3e1832452051428 
Merge: dc69dc2 0b5912b 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:09:18 2012 +0300 

    Merge branch 'master' of e:/temp/git2 

    Conflicts: 
     file.file 

commit 0b5912bd1a1cb9b78410fe5c0dc67845ca1deec5 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:46 2012 +0300 

    c8 

commit dc69dc25a1e0c9067cbca19fe6a1d078a19138a0 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:29 2012 +0300 

    c7 

commit f6d88da1ecc3106f6debe1eac80d4b02705bcecf 
Merge: d1a3c38 6134e66 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:05:05 2012 +0300 

    Merge branch 'master' of e:/temp/git1 

    Conflicts: 
     file.file 

commit d1a3c389416ff88e195e93def9a956fad1e63819 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:03:47 2012 +0300

GIT2

commit e1ee3b2756d4d8440ae3661df3fb3ec9af7cd55a 
Merge: 4296e1b 4f438f9 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:01:30 2012 +0300 

    Merge branch 'master' of e:/temp/git1 

    Conflicts: 
     file.file 

commit 4f438f9579939312689eb67e5fb7957d87cfa036 <-- this commit 
Author: Michael Nesterenko <[email protected]> 
Date: Mon Jun 25 00:00:31 2012 +0300 

    stuff after change 

commit 4296e1bd046c4008166cfc516ef5ee2ce98a27d1 
Author: Michael Nesterenko <[email protected]> 
Date: Sun Jun 24 23:57:14 2012 +0300 

    more stuff 

commit e91e833158bb44f54f418cc5c3e1832452051428 
Merge: dc69dc2 0b5912b 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:09:18 2012 +0300 

    Merge branch 'master' of e:/temp/git2 

    Conflicts: 
     file.file 

commit 0b5912bd1a1cb9b78410fe5c0dc67845ca1deec5 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:46 2012 +0300 

    c8 

commit dc69dc25a1e0c9067cbca19fe6a1d078a19138a0 
Author: Michael Nesterenko <[email protected]> 
Date: Mon May 7 02:06:29 2012 +0300

，承诺有不同的父母，但相同的SHA哈希。

来源

2012-06-24 michael nesterenko

是什么让您认为提交在每个存储库中有不同的父项？请在每个存储库中显示'git cat-file commit 4f438f9579939312689eb67e5fb7957d87cfa036'的结果。另外，你运行什么日志命令来生成你发布的输出？ –

@CharlesBailey，日志输出让我觉得如此。但出于某种原因，现在'git log'在两个存储库上显示'4f438f9579939312689eb67e5fb7957d87cfa036'的相同父提交。奇怪的！'git2'上的'git1'和'4296e1bd046c4008166cfc516ef5ee2ce98a27d1'上有'e91e833158bb44f54f418cc5c3e1832452051428'。 –

你提供什么选项来登录？如果你没有像'--graph'这样的东西，你不能看到实际的父关系，并会以合理的逻辑顺序看到你所要求的所有提交，但是你不能确定在另一个提交之前显示的提交是不管是直系后代还是非直系后代。 –

在同一个存储库的克隆中的两个不同的提交具有相同的id但不同的提交是极其不可能的。父母列表是散列提交的部分数据。要查看被散列可以运行数据：

git cat-file commit <id-of-commit>

被散列的实际数据是由一个标题：<type> <size>\0后跟提交的数据。例如。对于犯我混帐克隆：

$ printf 'commit %d\0' $(git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 | wc -c) >tmp.dat 
$ hexdump -C tmp.dat 
00000000 63 6f 6d 6d 69 74 20 33 30 34 00     |commit 304.| 
0000000b 
$ git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 >>tmp.dat 
$ sha1sum tmp.dat 
5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 tmp.dat

注意SHA1SUM提交ID匹配，并且父提交对象的一部分：

$ git cat-file commit 5498c5f05283cd248fd5e4f48cb8902e9ca6ce28 | grep parent 
parent 3ba46634202968045e05e4d7f969d97c61efa53d

git log输出提交的平面列表，但在提交git形成一个有向无环图。由于日志是一个扁平化的提交列表，它只会直接反映在简单线性历史记录的普通情况下对父代关系的提交。如果您有任何合并（或正在记录多个分支），您将无法直接从git log的输出中推断出亲子关系。

要显示从提交到父母的实际链接，您需要使用类似git log --graph（我通常建议使用--oneline）或图形可视化工具（如gitk）。

来源

2012-06-24 21:48:24

感谢您的回答。你能否说出一些可能导致'git log'以这种顺序安排提交（之前有错误的父提交）的原因？我一直认为下面的提交是父列表（或至少有一位父母）在该列表中位于较高位置。 –

我可以重复这种行为。父代提交没有问题，因为它们应该是。这似乎是'git log'显示提交的方式。这发生在一个存储库的硬重置以及随后的第二存储之后。 –

@mishanesterenko：日志是提交列表。仅仅因为一个提交出现在另一个提交之后并不一定意味着它是之前提交的父代。 'git log'没有显示“错误的父项”，因为它没有显示父项关系。当它不在时，你正在推断这个意思。 –

git commit integrity

回答

相关问题