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

Question

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

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

Кроме того, короткие ПОР, по крайней мере 4- знак длинный. Тем не менее, согласно книге Pro Git,

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

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

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

Answer 1

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

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" 
) 

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

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

Answer 2

Сценарий Jubob великолепный, поддержанный.

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

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

Для git project сам сегодня (ГИТ-на-ГИТ) это дает что-то вроде:

1788 4 
35086 5 
7881 6 
    533 7 
    39 8 
    4 9 

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

сравнения, гораздо больше проектов, таких как Linux kernel, имеет такое распределение сегодня:

6179 5 
446463 6 
139247 7 
10018 8 
655 9 
41 10 
3  11 

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