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

回答

相關問題