От чего зависит мерзавец SHA?
Мне было интересно, от каких параметров зависит git SHA? Я предполагаю, что были бы некоторые другие параметры, такие как метка времени и т. Д., Кроме содержания коммита, от которого зависит построение SHA.
Меня интересуют все такие параметры, от которых это зависит. Меня также интересует ситуация, когда все такие параметры будут одинаковыми или принудительно будут одинаковыми, что приведет к абсолютно одинаковому git SHA любых двух коммитов, сделанных двумя людьми на этой планете.
2 ответа
Для фиксации идентификатор зависит от контрольных сумм, по крайней мере...
- Идентификатор дерева (все файлы и каталоги), который состоит из...
- Содержимое всех файлов, а не diff, называется blob.
- Дерево каталогов (имена файлов и каталогов и как они организованы).
- Права доступа ко всем файлам и каталогам.
- ID родительского коммита.
- Лог-сообщение.
- Имя коммиттера, адрес электронной почты и дата.
- Имя автора и дата электронной почты.
Если вы измените что-либо в коммите, то изменится идентификатор фиксации.
Включение идентификаторов родительского коммита очень важно. Это означает, что два коммита с одинаковым содержимым, но построенные на разных родителях, будут по-прежнему иметь разные идентификаторы. Почему ты бы так поступил? Это означает, что если идентификаторы двух коммитов одинаковы, вы знаете, что их история одинакова. Это позволяет очень эффективно сравнивать и обновлять Git-репозитории. "У меня есть филиал foo на коммит ABC123, вы тоже? Отлично, мы синхронизированы!
Сравнивая Git с другими системами контроля версий, помните, что во многих популярных "надежных" системах, таких как Subversion или CVS, любой, у кого есть права доступа к файлам, может войти и незаметно изменить историю в центральном хранилище. С помощью Git такое вмешательство будет немедленно обнаружено, потому что оно изменит все идентификаторы нижестоящего коммита, или если они будут грубо сопоставлены с идентификаторами, содержимое будет полной чепухой.
Возможность столкновения SHA1 уже была рассмотрена. Короче говоря, в конфликте существующий объект выигрывает.
Вероятность случайного столкновения SHA1 настолько мала, что я надеюсь, что ваши страховки от астероидов, космических лучей и волков оплачены.
Если бы все 6,5 миллиарда людей на Земле занимались программированием, и каждую секунду каждый из них создавал код, эквивалентный всей истории ядра Linux (3,6 миллиона объектов Git), и помещал его в один огромный репозиторий Git, это заняло бы примерно 2 года. до тех пор, пока в этом хранилище не будет достаточно объектов, чтобы вероятность столкновения одного объекта SHA-1 составила 50%. Существует более высокая вероятность того, что каждый член вашей команды программистов будет атакован и убит волками в несвязанных инцидентах в одну и ту же ночь.
Серьезно, есть и поводы для беспокойства, например, 1 из 100 вероятности отказа диска. Как твои резервные копии?
В репозитории Git хранится несколько разных типов объектов. Объект BLOB-объектов хранит необработанные данные файла, а объект дерева - режим файла (например, доступен ли он только для чтения), тип и имя объекта.
Вы можете найти более подробную информацию в Git Community Book.
Хеш-значений так много, что вероятность случайного столкновения исчезающе мала.
Однако действительно идентичное содержимое будет иметь идентичный хеш: поэтому, если два человека независимо вносят одинаковые изменения в файл, тогда два (идентичных) объекта BLOB-объектов будут иметь одинаковый хэш; Объекты коммитов будут разными и будут иметь разные хэши, но оба коммита будут ссылаться на один и тот же хэш BLOB-объекта. Если эти два коммита будут позднее объединены, останется только одна копия большого двоичного объекта (это нормально, потому что содержимое идентично).