Оба Git и GitHub отображают короткие версии SHA - только первые 7 символов вместо всех 40 - и обе Git, и поддержка GitHub, берущие эти короткие SHA в качестве аргументов.
например. git show 962a9e8
например. https://github.com/joyent/node/commit/962a9e8
Учитывая, что пространство возможностей сейчас на порядок ниже, "просто" 268 миллионов, как Git и GitHub защищают от коллизий здесь? И как они справляются с ними?
Эти короткие формы предназначены только для упрощения визуального распознавания и облегчения вашей жизни . Git на самом деле ничего не урезает, внутренне все будет обработано с полным значением. Вы можете использовать частичный SHA-1 в удобное для вас время:
Git достаточно умен, чтобы понять, какое обязательство вы намереваетесь ввести, если вы предоставляете первые несколько символов, если ваш частичный SHA-1 имеет длину не менее четырех символов и недвусмысленную, то есть только один объект в текущий репозиторий начинается с частичного SHA-1.
У меня есть репозиторий с фиксацией с идентификатором 000182eacf99cde27d5916aa415921924b82972c.
git show 00018
показывает версию, но
git show 0001
печатает
error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
(Если вам интересно, это клон репозитория git для самого git, это фиксация - это тот, который сделал Линус Торвальдс в 2005 году.)
Две заметки здесь:
Если вы наберете y где угодно на странице GitHub, отображающей фиксацию, вы увидите полные 40 байт указанного фиксации.
Это иллюстрирует emboss: GitHub ничего не урезает.
И 7 бит не хватает с 2010 года в любом случае.
См. передать dce9648 самим Линусом Торвальдом (октябрь 2010 г., git 1.7.4.4):
Значение по умолчанию 7 происходит из-за довольно раннего развития git, когда семь шестнадцатеричных цифр были много (он охватывает около 250 миллионов хэш-значений). В то время я думал, что 65k ревизий было много (это было то, что мы собирались попасть в BK), и каждая ревизия имеет тенденцию быть примерно 5-10 новые объекты или около того, поэтому миллион объектов был большим числом.
(BK = BitKeeper)
В настоящее время ядро не является даже самым большим проектом git, и даже ядро имеет около 220 тыс. ревизий (намного больше, чем когда-либо было BK-дерево), и мы приближаемся к двум миллионам объектов. В этот момент семь шестнадцатеричных цифр по-прежнему уникальны для многих из них, но когда мы говоря о разнице в два порядка между количеством объектов и размером хэша, будут происходить столкновения в усеченных хеш-значениях. Он уже не близок к нереалистичному - это происходит все время.
Мы должны увеличить сокращение абзаца по умолчанию, которое было нереалистично мало, и добавить способ для людей установить собственный собственный проект по умолчанию в конфигурационном файле git.