Git-данные BLOB-объектов и другая информация

Question

Насколько я знаю, у двоичного объекта Git в качестве имени файла есть хэш SHA1, чтобы не дублировать файл в хранилище.

Например, если файл A имеет содержимое «abc» и имеет хэш SHA1 как «12345», пока содержимое не изменяется, коммиты / ветви могут указывать на тот же SHA1.

Но что произойдет, если файл A будет изменен на "def", чтобы иметь хэш SHA "23456"? Сохраняет ли Git файл A и измененный файл A (не только разницу, но и весь файл)?

• Если так, то почему? Не лучше ли хранить информацию о разнице?
• Если нет, то как diff отслеживает изменения в файле?
• Как насчет других систем VCS - CVS / SVN / Perforce ...?

ДОБАВЛЕНО

Следующие слова из «Книги сообщества Git» отвечают на большинство моих вопросов.

Важно отметить, что это сильно отличается от большинства систем SCM, с которыми вы, возможно, знакомы. Subversion, CVS, Perforce, Mercurial и другие используют системы Delta Storage - они хранят различия между одним коммитом и следующим. Git не делает этого - он сохраняет снимок того, как все файлы в вашем проекте выглядят в этой древовидной структуре каждый раз, когда вы фиксируете. Это очень важная концепция для понимания при использовании Git.

Answer 1

git хранит файлы по содержимому, а не по различиям, поэтому в вашем примере обе версии A ("abc" и "def") будут храниться в базе данных объектов.Лучше всего хранить целые объекты, потому что очень легко увидеть, совпадают ли две версии файла, или нет, просто сравнивая их SHA.Взгляните на git-book для получения подробной информации о том, как хранятся объекты.Это работает лучше, потому что, если файлы отслеживались с помощью diff, вам понадобилась бы вся история файла, чтобы восстановить его.Легко сделать в централизованной системе, но не в распределенной системе, где в файле может быть много разных изменений.

Git выполняет diff непосредственно из объектов.

Answer 2

Одной из целей дизайна git является скорость.Подумайте о том, чтобы хранить объекты в git как дельты, а не как уникальные объекты.

Если вы храните каждый уникальный BLOB-объект с помощью хэша SHA1, для извлечения содержимого из этого хэша SHA1 требуется только фиксированный расчет.Если вы начнете хранить дельты, вам придется реконструировать объект, и вычисления больше не будут фиксированными и могут увеличиваться без ограничений в зависимости от реализации.

Хороший способ понять проект - посмотреть на реальныйрепозиторий (примечание: рассылаемые электронные письма):

$ git cat-file commit HEAD
tree 21f9601e608cf62360fca43cd7f0bf05bb65bd23
parent 11507e17a7c823c379202ae344aa59fe5370a4fd
author John Doe <jd@example.com> 1273816361 -0400
committer John Doe <jd@example.com> 1273816361 -0400

Important Work

$ git ls-tree HEAD
100644 blob 2f6d9912344c299670551c9e9684a7cae800ec5d    .gitignore
...
100644 blob a3ddeb9dd0541b80981f2f78bbc500579a13459a    COPYING
040000 tree f1ac0acae2a4ab31c2a79b71f08ebd651136d706    contrib
...

Из этих двух команд видно, что коммит - это просто метаданные, один или несколько родителей и дерево.Дерево содержит один или несколько BLOB-объектов и деревьев.

Зная, что вы можете начать рассматривать сложность различных операций с репозиторием.Кончик ветви - это просто указатель на хеш коммита.Итак, начиная с этого, перечисление истории просто вопрос обхода родителей.Распечатка содержимого дерева просто означает обход дерева и всех поддеревьев.Извлечение содержимого файла осуществляется так же, как указано выше.

Конечно, всегда есть компромисс, и эта модель довольно неэффективна, хотя и обеспечивает автоматическую дедупликацию на уровне файлов, так как каждый уникальный файл тольконужно хранить один раз.Это эффективно устраняется с помощью packfile .Дельта-хранилище (используется в svn и т. Д.) Более компактно без сжатия, но в конечном итоге git сохраняет его более эффективно.

Для сравнения изменений вы можете начать со сравнения хэшей дерева, а затем, если онине совпадают, вы пересекаете дерево и сравниваете его сгустки и деревья и так далее.Поскольку модель разработана на основе атомарных фиксаций, различие в файлах обходится дороже, но не слишком разумно.