Может ли Git хранить файловые контейнеры в виде деревьев и BLOB-объектов?

Question

Git - это файловая система с адресным содержимым, в которой есть три типа объектов: BLOB-объекты, деревья и коммиты. В принципе, форматы контейнерных файлов, такие как ZIP, можно интерпретировать как похожую концепцию как отдельный файл (или ссылку), содержащий дерево в терминах Git. Хотя ZIP-файлы и другие типы контейнеров не имеют специальной обработки в Git, эти контейнеры просто хранятся в виде больших двоичных объектов.

Например, допустим, у меня есть ZIP-файл с несколькими файлами с их временными метками (timestamps (timestamps)не обрабатывается Git), пустые каталоги и наличие такого контейнера ZIP в репозитории Git могут считаться необходимыми (возможно, предварительно скомпилированные файлы JAR, часто редактируемые документы OpenOffice и т. д.). Теперь давайте рассмотрим, как изменяется контейнер. Это создаст совершенно другой объект с точки зрения Git, поэтому резкое увеличение хранилища будет происходить до тех пор, пока контейнер будет неоднократно изменяться. Я натолкнулся на интересный фильтр clean / smudge , который выполняет аналогичные действия, но он уничтожает исходный ZIP-файл при заполнении, перезаписывая исходный ZIP-файл, стирая исходные временные метки входа, возможно ZIP-комментарий и все, что может иметь ZIP-контейнеры (+насколько я понимаю, это затрудняет использование пустых репозиториев, поскольку они не содержат "очищенных" контейнеров ZIP, которые создаются только при проверке), поэтому этот фильтр меня мало интересует.

I 'Интересно, можно ли сказать Git хранить контейнеры (возможно, ZIP), как первоклассные граждане Git, такие как деревья и капли внутри? Я думаю, что он не поддерживает такой случай, хотя.

---

Обновление 1

Я был не прав, как люди говорят ниже, в Git есть четыре типа объектов: Я пропустил тегобъекты. Однако я думал, что они построены поверх коммитов, как это делают заметки (вероятно).

Answer 1

Большинство команд в git ожидают найти одно из 4 слов blob, tree, commit или tag в начале каждого объекта, будет почти невозможно добавить новыйтип объекта.

Вот ручной эксперимент:

# I created an object with a new type 'foo' :
$ cat .git/objects/70/c52a28ff2b01f46ccc0cdd03c61c569fd6fd54 | pigz -dz; echo
foo10.abcdefghij    # the '.' is actually '\0'

# all regular git commands start with a "unable to parse header of [object]" :
$ git show 70c52a28ff2b01f46ccc0cdd03c61c569fd6fd54
error: unable to parse 70c52a28ff2b01f46ccc0cdd03c61c569fd6fd54 header
error: unable to parse 70c52a28ff2b01f46ccc0cdd03c61c569fd6fd54 header
fatal: loose object 70c52a28ff2b01f46ccc0cdd03c61c569fd6fd54 (stored in .git/objects/70/c52a28ff2b01f46ccc0cdd03c61c569fd6fd54) is corrupt

$ git fsck
error: unable to parse header of .git/objects/70/c52a28ff2b01f46ccc0cdd03c61c569fd6fd54
error: 70c52a28ff2b01f46ccc0cdd03c61c569fd6fd54: object corrupt or missing: .git/objects/70/c52a28ff2b01f46ccc0cdd03c61c569fd6fd54
Checking object directories: 100% (256/256), done.

# etc ...

---

Можно было бы написать более полный нечеткий / чистый фильтр, который бы не только сохранял фактическое содержимое архива. , но все дополнительные данные (такие как метки времени, комментарии ...)

Вот одна из первых идей:

, если archive.zip содержит dir\file.txt:

• создать дерево с именем dir
• сохранить заголовок каталога в BLOB-объекте с известным именем (например, dheader)
• сохранить заголовок и содержимое для file.txt в двух различных BLOB-объектах (например, hfile.txt и _file.txt)
• и т. д. для других метаданных zip

Использование различных префиксов должно позволять вам четко разделять каждый типданных, которые вам нужно хранить

Второй будет:

• человеквозраст, чтобы упаковать все метаданные архива в один большой двоичный объект

и т. д.

В таком случае чистый фильтр будет иметь достаточно данных для восстановления того же архива.

Обратите внимание, что для "перестройки zip-файла" потребуется чистый фильтр, чтобы реализовать все возможные функции zip-архива (например, возможность сжатия во всех известных форматах, ...)