Примечание: вы можете запросить git rev-parse --shortсамый короткий и в то же время уникальный SHA1.
Смотрите " git получи короткий хеш из обычного хэша "
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
Как вы можете видеть в моем примере, SHA1 имеет длину 5, даже если я указал длину 4.
Для больших репозиториев 7 недостаточно с 2010 года, а коммит dce9648 сам Линус Торвальдс (git 1.7.4.4, октябрь 2010):
Значение по умолчанию 7 приходит с довольно раннего периода разработки git, когда семь шестнадцатеричных цифр было много (оно охватывает более 250 миллионов значений хеша).
В то время я думал, что 65 000 ревизий - это много (это было то, что мы собирались выпустить в БК), и каждая ревизия имеет тенденцию иметь около 5-10 новых объектов или около того, поэтому миллион объектов был большим числом.
(BK = BitKeeper)
В настоящее время ядро даже не является крупнейшим git-проектом, и даже ядро имеет около 220 тыс. Ревизий ( намного больше, чем когда-либо было дерево BK), и мы приближаемся к двум миллионам объектов.
На этом этапе семь шестнадцатеричных цифр по-прежнему уникальны для многих из них, но когда мы говорим только о разнице в два порядка между количеством объектов и размером хэша, в усеченных значениях хэша будут возникать коллизии.
Это уже даже близко к нереальному - это происходит постоянно.
Мы должны как увеличить аббревиатуру по умолчанию, которая была нереально малой, так и добавить способ, позволяющий людям устанавливать свой собственный проект по умолчанию в файле конфигурации git .
core.abbrev
Установите длину объекта, имена которого сокращены до.
Если не указано, многие команды сокращаются до 7 шестнадцатеричных чисел, что может быть недостаточно для того, чтобы сокращенные имена объектов оставались уникальными в течение достаточно длительного времени.
environment.c:
int minimum_abbrev = 4, default_abbrev = 7;
Примечание: Как прокомментировал ниже по marco.m , core.abbrevLengthбыл переименован в core.abbrevв том же Git 1.7.4.4 в фиксации a71f09f
Переименовать core.abbrevlengthобратно вcore.abbrev
В --abbrev=$nконце концов, это соответствует опции командной строки.
Совсем недавно, Линус добавил совершить e6c587c (для Git 2.11, Q4 2016):
(как указано в Матьё Moy «s ответ )
В довольно ранние времена мы почему-то решили сократить имена объектов до 7-шестнадцатеричных чисел, но по мере роста проектов становится все более вероятным, что такие короткие имена объектов, сделанные в более ранние дни и записанные в сообщениях журнала, перестают быть уникальными.
В настоящее время проекту ядра Linux требуется от 11 до 12 шестнадцатеричных чисел, в то время как самому Git требуются 10 шестнадцатеричных чисел для уникальной идентификации объектов, которые у них есть, в то время как многие небольшие проекты могут по-прежнему работать с исходным 7-шестнадцатеричным значением по умолчанию. Один размер не подходит для всех проектов.
Внедрите механизм, где мы оцениваем количество объектов в хранилище по первому запросу, чтобы сократить имя объекта с настройкой по умолчанию и придумать нормальное значение по умолчанию для хранилища. Исходя из того, что мы увидим столкновение в хранилище с 2^(2N)объектами при использовании имен объектов, укороченных до первых N битов, используйте достаточное количество шестнадцатеричных чисел, чтобы покрыть количество объектов в хранилище.
Каждый шестнадцатеричный код (4 бита), который мы добавляем к сокращенному имени, позволяет нам иметь в четыре раза (2 бита) столько объектов в хранилище.
Смотрите коммит e6c587c (01.10.2016) Линуса Торвальдса ( torvalds) .
Смотрите коммит 7b5b772 , коммит 65acfea (01 октября 2016 г.) от Junio C Hamano ( gitster) .
(Слиты Junio C Hamano - gitster- в фиксации bb188d0 , 3 октября 2016)
Это новое свойство (предполагающее разумное значение по умолчанию для значения аббревиатуры SHA1) напрямую влияет на то, как Git вычисляет свой собственный номер версии для выпуска .