Достаточно ли 10-значной аббревиатуры git hash?

Сколько возможных хеш-значений нужно, чтобы избежать конфликтов между N элементами? Если вы помните парадокс дня рождения, ответ намного меньше, чем N.

Обратим вопрос: для N=16^10 возможных значений хэшей, что соответствует 10 шестнадцатеричным цифрам сокращенных кодов ревизий git, при скольких ревизиях вероятность совпадения хэшей ревизий возрастает до 50%? Прямой подсчет показывает, что если у вас есть 1234603 ревизии, вероятность того, что две из них будут иметь одинаковый 10-значный хэш, составляет 50%.

Теперь миллион или около того ревизий не редкость в больших активных репозиториях. Кто-нибудь здесь сталкивался с конфликтом git hash в вашей работе? Теоретически это должно было произойти.


181
2

Ответы:

Решено

Git автоматически масштабирует длину сокращенных хэшей по мере увеличения количества объектов, поэтому обычно это не проблема. Кроме того, если сокращенный хеш при нормальной длине будет неоднозначным, Git автоматически создаст более длинное однозначное значение. Некоторые команды позволяют вам контролировать длину сокращений с помощью параметра --abbrev, если вам нужно конкретное значение, а параметр core.abbrev может переопределить значение по умолчанию.

Однако эти имена обязательно уникальны только в момент их создания, поэтому, если вы создаете инструменты, которым необходимо работать с ревизиями, они всегда должны работать с полными идентификаторами объектов. Также обратите внимание, что ведется работа по переходу на использование SHA-256, поэтому при написании инструментов не следует делать никаких предположений о длине конкретного полного идентификатора объекта.


Как объяснено в "Какая часть Git SHA в общем считается необходимой для уникальной идентификации изменения в данной кодовой базе?", вы можете получить минимальную требуемую длину с помощью git rev-parse --short.

 git rev-parse --short=4

Но если вы хотите быть уверенным и работать только с полной длиной:

В Git 2.31 (1 квартал 2021 г.) для переменной конфигурации «core.abbrev» можно установить значение «no», чтобы не использовать аббревиатуру независимо от алгоритма хеширования.

И это будет важно, когда Git переключится с SHA1 на SHA2.

См. совершить a9ecaa0 (01 сентября 2020 г.) от Эрик Вонг (ele828).
(Merged by Junio C Hamano -- gitster -- in commit 6dbbae1, 15 Jan 2021)

core.abbrev=no: disables abbreviations

Signed-off-by: Eric Wong

This allows users to write hash-agnostic scripts and configs by disabling abbreviations.

Using "-c core.abbrev=40" will be insufficient with SHA-256, and "-c core.abbrev=64" won't work with SHA-1 repos today.

[jc: tweaked implementation, added doc and a test]

git config теперь включает в свой справочная страница:

If set to "no", no abbreviation is made and the object names are shown in their full length.