Uwaga: możesz poprosić git rev-parse --shorto najkrótszy i jednocześnie unikalny SHA1.
Zobacz „ git dostaje krótki skrót od zwykłego skrótu ”
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
Jak widać w moim przykładzie, SHA1 ma długość 5, nawet jeśli określiłem długość 4.
W przypadku dużych transakcji repo 7 nie wystarczy od 2010 r., A sam dce9648 sam Linus Torvalds (git 1.7.4.4, paź 2010):
Domyślna wartość 7 pochodzi z dość wczesnego rozwoju gita, kiedy siedem cyfr szesnastkowych było dużo (obejmuje około 250 milionów wartości skrótu).
Wtedy myślałem, że 65 000 wersji było dużo (to właśnie mieliśmy trafić w BK), a każda wersja zawiera około 5-10 nowych obiektów, więc milion obiektów to duża liczba.
(BK = BitKeeper)
Obecnie jądro nie jest nawet największym projektem git, a nawet jądro ma około 220 000 wersji ( znacznie większych niż kiedykolwiek było drzewo BK), a my zbliżamy się do dwóch milionów obiektów.
W tym momencie siedem cyfr szesnastkowych jest wciąż unikatowych dla wielu z nich, ale kiedy mówimy o tylko dwóch rzędach wielkości różnicy między liczbą obiektów a rozmiarem skrótu, wystąpią kolizje w obciętych wartościach skrótu.
Nie jest już nawet nierealne - zdarza się to cały czas.
Powinniśmy zarówno zwiększyć domyślny skrót, który był nierealistycznie mały, jak i dodać sposób, w jaki ludzie mogą ustawić własny domyślny projekt w pliku konfiguracyjnym git .
core.abbrev
Ustaw długość nazw obiektów, które są skracane.
Jeśli nie jest określony, wiele poleceń skraca się do 7 cyfr szesnastkowych, co może nie wystarczyć, aby skrócone nazwy obiektów pozostały unikalne przez wystarczająco długi czas.
environment.c:
int minimum_abbrev = 4, default_abbrev = 7;
Uwaga: Jak skomentował poniżej przez marco.m , core.abbrevLengthzostał przemianowany na core.abbrevw tym samym Git 1.7.4.4 w popełnić a71f09f
Zmień nazwę z core.abbrevlengthpowrotem nacore.abbrev
W --abbrev=$nkońcu odpowiada opcji wiersza poleceń.
Niedawno, Linus dodane popełnić e6c587c (dla Git 2.11, Q4 2016)
(jak wspomniano w Matthieu Moy „s odpowiedzi )
W dość wczesnych dniach w jakiś sposób postanowiliśmy skrócić nazwy obiektów do 7-heksdigitów, ale wraz z rozwojem projektów coraz bardziej prawdopodobne jest, że tak krótkie nazwy obiektów powstają we wcześniejszych dniach i są zapisywane w komunikatach dziennika jako niepowtarzalne.
Obecnie projekt jądra Linuksa potrzebuje 11 do 12 heksdigitów, podczas gdy sam Git potrzebuje 10 hexdigitów, aby jednoznacznie zidentyfikować posiadane obiekty, podczas gdy wiele mniejszych projektów wciąż może być w porządku z oryginalną wartością domyślną 7-hexdigit. Jeden rozmiar nie pasuje do wszystkich projektów.
Wprowadź mechanizm, w którym szacujemy liczbę obiektów w repozytorium przy pierwszym żądaniu skrócenia nazwy obiektu z ustawieniem domyślnym i wymyślenia rozsądnego ustawienia domyślnego dla repozytorium. W oparciu o oczekiwanie, że zobaczymy kolizję w repozytorium z 2^(2N)obiektami przy użyciu nazw obiektów skróconych do pierwszych N bitów, użyj wystarczającej liczby heksdigitów, aby pokryć liczbę obiektów w repozytorium.
Każdy hexdigit (4 bity), który dodajemy do skróconej nazwy, pozwala nam mieć cztery razy (2 bity) tyle obiektów w repozytorium.
Zobacz commit e6c587c (01 października 2016) autorstwa Linusa Torvaldsa ( torvalds) .
Zobacz commit 7b5b772 , commit 65acfea (01 października 2016) autor: Junio C Hamano ( gitster) .
(Połączone przez Junio C Hamano - gitster- w commit bb188d0 , 03 października 2016)
Ta nowa właściwość (odgadnięcie rozsądnej wartości domyślnej wartości skrótu SHA1) ma bezpośredni wpływ na sposób, w jaki Git oblicza własny numer wersji do wydania .