3 回答

TA貢獻2080條經驗 獲得超4個贊
Pro Git手冊的第7章實際上回答了這個問題:
通常,八個到十個字符足以在一個項目中唯一。最大的Git項目之一Linux內核開始需要在40個字符中保持12個字符以保持唯一性。
短SHA的Git默認值為7位數,因此對于大多數項目來說都可以。如前所述,內核團隊增加了幾次,因為有數十萬次提交。因此,對于您的約3萬次提交,8或10位數字應該是完美的。

TA貢獻1858條經驗 獲得超8個贊
您可以要求git rev-parse --short最短但唯一的SHA1。
請參閱“ git從常規哈希中獲取短哈希 ”
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
如您在示例中所見,即使我指定的長度為4,SHA1的長度也為5。
對于大型存儲庫,自2010年以來7個還不夠,因此請 Linus Torvalds本人提交dce9648(git 1.7.4.4,2010年10月):
默認值7來自git開發的相當早的時候,當時7個十六進制數字很多(它涵蓋了大約250+百萬個哈希值)。
那時,我認為65k修訂版本很多(這是我們在BK中要達到的版本),每個修訂版本通常大約有5-10個新對象,所以一百萬個對象是一個很大的數目。
(BK = BitKeeper)
這些天來,內核甚至不是最大的Git項目,甚至內核約220K版本(多比BK樹曾是大),我們正在接近200萬級的對象。
那時,對于許多字符來說,七個十六進制數字仍然是唯一的,但是當我們談論的是對象數量和散列大小之間僅兩個數量級的差異時,截斷的散列值將存在沖突。
它甚至不再接近于不現實-它一直在發生。
我們都應該增加一個不切實際的很小的默認縮寫,并增加人們在git config文件中設置自己的默認每個項目的方法。
core.abbrev
設置長度對象名稱的縮寫。
如果未指定,則許多命令縮寫為7個十六進制數字,這可能不足以使縮寫對象名稱在足夠長的時間內保持唯一。
environment.c:
int minimum_abbrev = 4, default_abbrev = 7;
注意:如下面的marco.m所評論,在提交a71f09f中的同一Git 1.7.4.4中core.abbrevLenght被重命名。core.abbrev
重命名core.abbrevlength為core.abbrev
--abbrev=$n畢竟它對應于命令行選項。
最近,Linus在提交中提交了e6c587c(針對Git 2.11,2016年第4季度):(
如Matthieu Moy的回答中所述)
在相當早的日子里,我們以某種方式決定將對象名稱縮寫為7個十六進制,但是隨著項目的發展,越來越早地看到這么短的對象名稱并記錄在日志消息中的可能性越來越小。
當前,Linux內核項目需要11到12個十六進制數,而Git本身需要10個十六進制數來唯一標識它們具有的對象,而許多較小的項目可能仍然可以使用原始的7十六進制數。單一尺寸并不適合所有項目。
引入一種機制,在該機制下,我們會在第一次請求時估計存儲庫中的對象數量,以使用默認設置來縮寫對象名稱,并為存儲庫提出一個合理的默認值?;陬A期,2^(2N)當使用對象名稱縮短到前N位時,在存儲庫中會與對象發生沖突,請使用足夠數量的十六進制數來覆蓋存儲庫中的對象數量。
我們在縮寫名稱中添加的每個十六進制數字(4位)使我們可以在存儲庫中擁有四倍(2位)的對象。
參見Linus Torvalds()的commit e6c587c(2016年10月1日)。 參見Junio C Hamano()提交的commit 7b5b772和commit 65acfea(2016年10月1日)。(通過合并JUNIO?濱野- -在提交bb188d0,2016年10月3日)torvalds
gitster
gitster
這個新屬性(猜測SHA1縮寫值的合理默認值)直接影響Git如何計算自己的版本號以進行發布。

TA貢獻1847條經驗 獲得超7個贊
這被稱為生日問題。
對于小于1/2的概率,可以將碰撞概率近似為
p?=(n 2)/(2m)
其中n是項目數,m是每個項目的可能性數。
十六進制字符串的可能數目為16 c,其中c為字符數。
因此對于8個字符和30K次提交
30K?= 2 15
P?=(N 2)/(2M)?=((2 15)2)/(2 * 16 8)= 2 30 /2 33 =?
增加到12個字符
P?=(N 2)/(2M)?=((2 15)2)/(2 * 16 12)= 2 30 /2 49 = 2 -19
- 3 回答
- 0 關注
- 957 瀏覽
添加回答
舉報