И Git, и GitHub отображают короткие версии SHA — только первые 7 символов вместо всех 40 — и Git, и GitHub поддерживают использование этих коротких SHA в качестве аргументов.
E.g. git show 962a9e8
Например. https://github.com/joyent/node/commit/962a9e8
Учитывая, что пространство возможностей теперь на несколько порядков меньше, «всего» 268 миллионов, как Git и GitHub защищает от столкновений здесь? И как они с ними справляются?
Эти короткие формы предназначены только для упрощения визуального распознавания и облегчения вашей жизни легче. Git на самом деле ничего не усекает, внутри все будет обрабатываться с полным значением. Однако вы можете использовать частичный SHA-1 по своему усмотрению:
Git достаточно умен, чтобы понять, какую фиксацию вы хотели ввести, если вы укажете первые несколько символов, если ваш частичный SHA-1 имеет длину не менее четырех символов и однозначен, то есть только один объект в текущем репозитории начинается с что частичный SHA-1.
--abbrev-commit команде git log, выходные данные будут использовать более короткие значения, но сохранят их уникальность; по умолчанию он использует семь символов, но при необходимости делает их длиннее, чтобы сохранить однозначность SHA-1.
- person Aseem Kishore; 23.08.2011
У меня есть репозиторий с фиксацией с идентификатором 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 году.)
0001), вы можете сделать git rev-list --all --objects | grep ^0001. После того, как у вас есть список возможных полных SHA1, вы можете выполнить git show для каждого из них.
- person Mikko Rantalainen; 22.01.2013
Два примечания здесь:
Если вы введете y в любом месте страницы GitHub, отображающей коммит, вы увидите полные 40 байт указанного коммита.
Это иллюстрирует emboss: GitHub ничего не обрезает.
И 7 шестнадцатеричных цифр (28 бит) в любом случае недостаточно с 2010 года.
См. от самого Линуса Торвальдса (октябрь 2010 г., git 1.7.4.4):
Значение по умолчанию, равное 7, появилось довольно рано в разработке git, когда семь шестнадцатеричных цифр было много (охватывает около 250+ миллионов хеш-значений). Тогда я думал, что 65 тысяч ревизий — это много (это то, что мы собирались сделать в BK), и каждая ревизия, как правило, содержит около 5-10 новых объектов, так что миллион объектов — это большое число.
(БК = BitKeeper)
В наши дни ядро даже не является самым большим проектом git, и даже ядро имеет около 220 тысяч ревизий (намного больше, чем когда-либо было дерево BK), и мы приближаемся к двум миллионам объектов. В этот момент семь шестнадцатеричных цифр по-прежнему уникальны для многих из них, но когда мы говорим о разнице всего в два порядка между количеством объектов и размером хэша, будут коллизии в усеченные хэш-значения. Это уже даже близко не нереально — это происходит постоянно.
Мы должны как увеличить аббревиатуру по умолчанию, которая была нереально маленькой, так и и добавить возможность для людей устанавливать свои собственные значения по умолчанию для каждого проекта в файле конфигурации git.
