Я лишь расширяю ответ на @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 обрабатывает перемещение и переименование лучше, чем другие системы контроля версий.
Сделай сам (внешнее)
- Шаг 6. Создайте еще один пустой файл с другим
filename
в том же каталоге.
- Шаг 7. Сравните хэши обоих файлов.
Примечание.
В ссылке не упоминается, как хешируется объект tree
. Я не уверен в алгоритме и параметрах, однако, по моим наблюдениям, он, вероятно, вычисляет хэш на основе всех blobs
и trees
(вероятно, их хэшей), которые он содержит
person
Lordbalmon
schedule
05.03.2015