Я только расширяю ответ @Leif Gruenwoldt
и детализирую то, что указано в ссылке, предоставленной@Leif Gruenwoldt
Сделай сам..
- Шаг 1. Создайте пустой текстовый документ (имя не имеет значения) в вашем репозитории.
- Шаг 2. Подготовьте и зафиксируйте документ
- Шаг 3. Определите хэш большого двоичного объекта, выполнив
git ls-tree HEAD
- Шаг 4. Найдите хэш капли
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
- Шаг 5. Избавьтесь от удивления и прочтите ниже.
Как GIT вычисляет хэши коммитов
Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)
Текст blob⎵
является постоянным префиксом, а \0
также постоянным и NULL
символом. Значения <size_of_file>
и <contents_of_file>
различаются в зависимости от файла.
См .: Каков формат файла объекта фиксации git?
И все, ребята!
Но ждать! , вы заметили, что <filename>
это не параметр, используемый для вычисления хэша? Два файла потенциально могут иметь одинаковый хэш, если их содержимое одинаково безразлично к дате и времени создания и их имени. Это одна из причин, по которой Git обрабатывает перемещение и переименование лучше, чем другие системы контроля версий.
Сделай сам (Ext)
- Шаг 6. Создайте еще один пустой файл с другим
filename
в том же каталоге.
- Шаг 7. Сравните хэши обоих файлов.
Примечание:
В ссылке не упоминается, как tree
хешируется объект. Я не уверен в алгоритме и параметрах, однако, по моим наблюдениям, он, вероятно, вычисляет хэш на основе всех blobs
и trees
(вероятно, их хешей), которые он содержит