В моем репо, как долго должен быть самый длинный префикс хэша, чтобы предотвратить перекрытие?

Флаг --abbrev-commit может использоваться совместно с git log и git rev-list, чтобы показать частичные префиксы вместо полных 40-символьных SHA-1 хэшей объектов фиксации. Согласно Pro Git book,

он по умолчанию использует семь символов, но делает их дольше, если необходимо, чтобы сохранить SHA-1 однозначным [...]

Кроме того, короткие SHA имеют длину не менее 4 символов. Тем не менее, согласно книге Pro Git,

Как правило, от восьми до десяти символов более чем достаточно, чтобы быть уникальным в рамках проекта.

В качестве примера ядро Linux, представляющее собой довольно большой проект с более чем 450 тыс. транзакциями и 3,6 миллиона объектов, не имеет двух объектов, SHA-1 которых перекрываются больше, чем первые 11 символов.

Поскольку длина самого длинного префикса, необходимого для предотвращения любого перекрытия между всеми префиксными хешами объектов фиксации (11, в случае ядра Linux), является грубым индикатором размера репо, я хотел бы программно определить соответствующее количество в моем собственном локальном репозитории. Как я могу это сделать?

Ответ 1

Следующая оболочка script, при запуске в локальном репо, печатает длину самого длинного префикса, необходимого для предотвращения любого совпадения между всеми префиксными хешами объектов фиксации этого репозитория.

MAX_LENGTH=4;

git rev-list --abbrev=4 --abbrev-commit --all | \
  ( while read -r line; do
      if [ ${#line} -gt $MAX_LENGTH ]; then
        MAX_LENGTH=${#line};
      fi
    done && printf %s\\n "$MAX_LENGTH"
  )

В последний раз, когда я отредактировал этот ответ, script напечатал

"9" при запуске в клоне Git -project repo,
"9" при запуске в клоне OpenStack repo,
"11" при запуске в клоне репо Linux-kernel.

Ответ 2

Jubob script отлично, поддерживается.

Если вы хотите получить представление о распределении минимальной фиксации-хэш-длины, вы можете запустить этот однострочный файл:

git rev-list --abbrev=4 --abbrev-commit --all | ( while read -r line; do echo ${#line}; done; ) | sort -n | uniq -c

Для git project сегодня (git -on- git), это дает что-то вроде:

... дает 1788, который может быть представлен однозначно с хешем 4 - char (или ниже, это Git минимальное сокращение) и 4, для чего требуется 9 -of-40 символов хэша для однозначного выбора.

Для сравнения, гораздо более крупный проект, такой как ядро Linux, имеет это распределение сегодня:

Таким образом, с базой данных из почти 5 миллионов объектов и фиксацией 600 тыс., в настоящее время 3 коммита требуют 11 из 40 шестнадцатеричных цифр, чтобы отличить их от всех других коммитов.