Достаточно ли 10 шестнадцатеричных аббревиатур git hash?

Question

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

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

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

Answer 1

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

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