Как Git (Hub) обрабатывает возможные столкновения от коротких SHA? - PullRequest
Новая
       30

Как Git (Hub) обрабатывает возможные столкновения от коротких SHA?

52 голосов
/ 20 августа 2011

И Git, и GitHub отображают короткие версии SHA - только первые 7 символов вместо всех 40 - и Git и GitHub поддерживают использование этих коротких SHA в качестве аргументов.

Например git show 962a9e8

Например https://github.com/joyent/node/commit/962a9e8

Учитывая, что пространство возможностей теперь на порядки ниже, "просто" 268 миллионов , как Git и GitHub защищают от столкновений здесь?И как они с ними справляются?

Ответы [ 3 ]

56 голосов
/ 20 августа 2011

Эти короткие формы предназначены только для упрощения визуального распознавания и облегчения вашей жизни .Git на самом деле ничего не усекает, внутри все будет обработано с полным значением.Вы можете использовать частичный SHA-1 по своему усмотрению, хотя:

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

30 голосов
/ 20 августа 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 году.)

12 голосов
/ 09 января 2014

Две заметки здесь:

  • Если вы введете y в любом месте на странице GitHub, отображающей коммит, вы увидите все 40 байтов указанного коммита.
    Это иллюстрирует точку emboss : GitHub ничего не усекает.

  • И, тем не менее, с 2010 года 7 шестнадцатеричных цифр (28 бит) недостаточно.
    См. commit dce9648 самого Линуса Торвальдса (октябрь 2010, git 1.7.4.4):

Значение по умолчанию 7 пришло из довольно раннего периода разработки git, когда семь шестнадцатеричных цифр было много (оно охватывает около 250+ миллионов значений хеша). Тогда я думал, что 65 000 ревизий - это много (это было то, что мы собирались выпустить в БК), и каждая ревизия имеет тенденцию быть 5-10. новые объекты или около того, поэтому миллион объектов был большим числом.

(BK = BitKeeper)

В наши дни ядро ​​даже не является крупнейшим git-проектом, и даже ядро ​​имеет около 220k ревизий ( намного больше, чем когда-либо было дерево BK), и мы приближаемся к двум миллионам объектов. На этом этапе семь шестнадцатеричных цифр по-прежнему уникальны для многих из них, но когда мы Если говорить о разнице в два порядка между количеством объектов и размером хеша, то будет коллизиями в усеченных значениях хеша. Это уже даже близко к нереальному - это происходит постоянно.

Мы должны оба увеличить аббревиатуру по умолчанию, которая была нереально малой, и добавить способ, позволяющий людям устанавливать свои собственные настройки по умолчанию для каждого проекта в файле конфигурации git.

...