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