В моем репо, как долго должен быть самый длинный префикс хэша, чтобы предотвратить перекрытие?
Флаг --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 напечатал
Ответ 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
35086 5
7881 6
533 7
39 8
4 9
... дает 1788, который может быть представлен однозначно с хешем 4 - char (или ниже, это Git минимальное сокращение) и 4, для чего требуется 9 -of-40 символов хэша для однозначного выбора.
Для сравнения, гораздо более крупный проект, такой как ядро Linux, имеет это распределение сегодня:
6179 5
446463 6
139247 7
10018 8
655 9
41 10
3 11
Таким образом, с базой данных из почти 5 миллионов объектов и фиксацией 600 тыс., в настоящее время 3 коммита требуют 11 из 40 шестнадцатеричных цифр, чтобы отличить их от всех других коммитов.
