例如，如果要構(gòu)建一個目錄結(jié)構(gòu)，該目錄結(jié)構(gòu)為Git存儲庫中的提交命名了一個目錄，并且您希望它足夠短以至于不讓您流血，但又要足夠長以使它碰撞的機(jī)會可以忽略不計，通常需要多少SHA子字符串？假設(shè)我要唯一標(biāo)識此更改：https : //github.com/wycats/handlebars.js/commit/e62999f9ece7d9218b9768a908f8df9c11d7e920我最多只能使用前四個字符：https : //github.com/wycats/handlebars.js/commit/e629但是我覺得那會很冒險。但是假設(shè)某個代碼庫可能在幾年內(nèi)可能會發(fā)生（例如）3萬次更改，那么如果我使用8個字符，發(fā)生沖突的機(jī)會是多少？12點？是否存在通常被認(rèn)為可以接受的數(shù)字？
3 回答
犯罪嫌疑人X
TA貢獻(xiàn)2080條經(jīng)驗 獲得超4個贊
Pro Git手冊的第7章實際上回答了這個問題：
通常，八個到十個字符足以在一個項目中唯一。最大的Git項目之一Linux內(nèi)核開始需要在40個字符中保持12個字符以保持唯一性。
短SHA的Git默認(rèn)值為7位數(shù)，因此對于大多數(shù)項目來說都可以。如前所述，內(nèi)核團(tuán)隊增加了幾次，因為有數(shù)十萬次提交。因此，對于您的約3萬次提交，8或10位數(shù)字應(yīng)該是完美的。
猛跑小豬
TA貢獻(xiàn)1858條經(jīng)驗 獲得超8個贊
您可以要求git rev-parse --short最短但唯一的SHA1。
請參閱“ git從常規(guī)哈希中獲取短哈希 ”
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
如您在示例中所見，即使我指定的長度為4，SHA1的長度也為5。
對于大型存儲庫，自2010年以來7個還不夠，因此請 Linus Torvalds本人提交dce9648（git 1.7.4.4，2010年10月）：
默認(rèn)值7來自git開發(fā)的相當(dāng)早的時候，當(dāng)時7個十六進(jìn)制數(shù)字很多（它涵蓋了大約250+百萬個哈希值）。
那時，我認(rèn)為65k修訂版本很多（這是我們在BK中要達(dá)到的版本），每個修訂版本通常大約有5-10個新對象，所以一百萬個對象是一個很大的數(shù)目。
（BK = BitKeeper）
這些天來，內(nèi)核甚至不是最大的Git項目，甚至內(nèi)核約220K版本（多比BK樹曾是大），我們正在接近200萬級的對象。
那時，對于許多字符來說，七個十六進(jìn)制數(shù)字仍然是唯一的，但是當(dāng)我們談?wù)摰氖菍ο髷?shù)量和散列大小之間僅兩個數(shù)量級的差異時，截斷的散列值將存在沖突。
它甚至不再接近于不現(xiàn)實-它一直在發(fā)生。
我們都應(yīng)該增加一個不切實際的很小的默認(rèn)縮寫，并增加人們在git config文件中設(shè)置自己的默認(rèn)每個項目的方法。
core.abbrev
設(shè)置長度對象名稱的縮寫。
如果未指定，則許多命令縮寫為7個十六進(jìn)制數(shù)字，這可能不足以使縮寫對象名稱在足夠長的時間內(nèi)保持唯一。
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畢竟它對應(yīng)于命令行選項。
最近，Linus在提交中提交了e6c587c（針對Git 2.11，2016年第4季度）：（
如Matthieu Moy的回答中所述）
在相當(dāng)早的日子里，我們以某種方式?jīng)Q定將對象名稱縮寫為7個十六進(jìn)制，但是隨著項目的發(fā)展，越來越早地看到這么短的對象名稱并記錄在日志消息中的可能性越來越小。
當(dāng)前，Linux內(nèi)核項目需要11到12個十六進(jìn)制數(shù)，而Git本身需要10個十六進(jìn)制數(shù)來唯一標(biāo)識它們具有的對象，而許多較小的項目可能仍然可以使用原始的7十六進(jìn)制數(shù)。單一尺寸并不適合所有項目。
引入一種機(jī)制，在該機(jī)制下，我們會在第一次請求時估計存儲庫中的對象數(shù)量，以使用默認(rèn)設(shè)置來縮寫對象名稱，并為存儲庫提出一個合理的默認(rèn)值。基于預(yù)期，2^(2N)當(dāng)使用對象名稱縮短到前N位時，在存儲庫中會與對象發(fā)生沖突，請使用足夠數(shù)量的十六進(jìn)制數(shù)來覆蓋存儲庫中的對象數(shù)量。
我們在縮寫名稱中添加的每個十六進(jìn)制數(shù)字（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縮寫值的合理默認(rèn)值）直接影響Git如何計算自己的版本號以進(jìn)行發(fā)布。
aluckdog
TA貢獻(xiàn)1847條經(jīng)驗 獲得超7個贊
這被稱為生日問題。
對于小于1/2的概率，可以將碰撞概率近似為
p?=（n 2）/（2m）
其中n是項目數(shù)，m是每個項目的可能性數(shù)。
十六進(jìn)制字符串的可能數(shù)目為16 c，其中c為字符數(shù)。
因此對于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 關(guān)注
- 976 瀏覽
添加回答
舉報
0/150
提交
取消