Может ли git обрабатывать zip файлы как каталоги и файлы внутри zip как blobs?

Сценарий

Представьте, что мне приходится работать с некоторыми моими файлами, которые всегда хранятся в файлах .zip. Некоторые из файлов внутри zip - небольшие текстовые файлы и часто меняются, в то время как другие больше, но, к счастью, довольно статичны (например, изображения).

Если я хочу разместить эти zip файлы внутри репозитория git, каждый почтовый индекс обрабатывается как blob, поэтому всякий раз, когда я фиксирую репозиторий, увеличивается размер zip файла... даже если только один небольшой текстовый файл внутри изменено!

Почему это реалистично

MS Word 2007/2010 .docx и файлы Excel .xlsx являются ZIP файлами...

Что я хочу

Есть ли какой-нибудь способ сообщить git не обрабатывать zips как файлы, а скорее как каталоги и обрабатывать их содержимое в виде файлов?

Преимущества

значительно меньший размер репо, т.е. более быстрая передача/резервное копирование
Показать изменения с помощью Git для zip будет автоматически работать

Но он не может работать, вы говорите?

Я понимаю, что без дополнительных метаданных это приведет к некоторой двусмысленности: на git checkout Git нужно будет решить, следует ли создавать foo.zip/bar.txt в качестве файла в обычном каталоге или в zip файле. Однако это можно было бы решить с помощью опций конфигурации, я бы подумал.

Две идеи о том, как это можно сделать (если он еще не существует)

используя библиотеку, такую как minizip или IO::Compress::Zip внутри git
каким-то образом добавляет уровень файловой системы, так что Git фактически видит zip файлы в качестве каталогов для начала с

Ответ 1

Это не существует, но оно может легко существовать в текущей структуре. Так же, как git действует по-разному с отображением двоичных или ascii файлов при выполнении diff, можно сказать, что он предлагает специальную обработку определенным типам файлов через интерфейс конфигурации.

Если вы не хотите менять базу кода (хотя это довольно классная идея, которую вы получили), вы можете также script для себя, используя pre-commit и post-checkout hooks, чтобы распаковать и сохранить файлы, а затем вернуть их в их .zip-состояние при проверке. Вам придется ограничивать действия только теми файлами blobs/indexes, которые указаны git add.

В любом случае это небольшая работа - это просто вопрос о том, комментирует ли другой git, что происходит и хорошо играет.

Ответ 2

Используйте bup (подробно представлен в GitMinutes # 24)

Это единственная git -подобная система, предназначенная для работы с большими (даже очень большими) файлами, что означает, что каждая версия zip файла будет только увеличивать репо из его дельта (вместо полной дополнительной копии)

Результатом является фактическое репо git, которое может прочитать обычная команда git.

Я подробно расскажу, как bup отличается от git в git большими файлами.

Любое другое обходное решение (например git-annex) не совсем удовлетворительно, как описано в разделе "git-annex с большими файлами.

Ответ 3

Не уверен, что кто-то все еще интересуется этим вопросом. Я столкнулся с теми же проблемами, и вот мое решение, которое использует фильтр файлов git.

Изменить: Во-первых, я не могу утверждать, что это понятно, но это ответ на вопрос ОП! Прочитайте все предложение, прежде чем комментировать. Кроме того, благодаря @Toon Krijthe за советом, чтобы прояснить решение на месте.

Мое решение - использовать фильтр для "плоского" zip файла в монолитный расширенный (может быть огромный) текстовый файл. Во время git добавить/зафиксировать zip файл будет автоматически разворачиваться в этот текстовый формат для нормального изменения текста, а во время проверки он автоматически застегнут.

Текстовый файл состоит из записей, каждый из которых представляет файл в zip. Таким образом, вы можете, что этот текстовый файл является текстовым изображением для оригинального zip. Если файл в zip является текстом на деле, он копируется в текстовый файл; в противном случае он кодируется base64 перед копированием в файл текстового формата. Это всегда сохраняет текстовый файл текстовым файлом.

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

Для получения дополнительной информации и кода прототипа вы можете прочитать следующую ссылку:

Фильтр файлов Zippey git

Кроме того, кредит на место, которое вдохновило меня на это решение: Описание работы фильтра файлов

Ответ 4

http://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/

(Примечание: за комментарий от Ruben, это только о получении правильного разбора, хотя и не об открытии распакованных файлов.)

Откройте файл ~/.gitconfig(создайте, если он уже не существует) и добавьте следующая строфа:

[diff "zip" ] textconv = unzip -c -a

Что он делает, это использовать "unzip -c -a FILENAME" для преобразования вашего zip файла в текст ASCII (unzip -c распакуется в STDOUT). Следующее - создайте/измените файл REPOSITORY/.gitattributes и добавьте следующие

*. pptx diff = zip

который сообщает git использовать zip-diffing описание из config для файлы, определяющие данную маску (в этом случае все, что заканчивается .pptx). Теперь git diff автоматически распаковывает файлы и различает Выход ASCII, который немного лучше, чем просто "бинарные файлы". С другой стороны, к запутанному беспорядку, который соответствует XML файлов pptx, это не помогает много, но для ZIP файлов, включая текст (например, например, архивы исходного кода), это на самом деле довольно удобно.

Ответ 5

Думаю, вам понадобится установить zip файл в файловую систему. Я не использовал его, но рассмотрю FUSE:

http://code.google.com/p/fuse-zip/

Существует также ZFS для Windows и Linux:

http://users.telenet.be/tfautre/softdev/zfs/

Ответ 6

Часто возникают проблемы с предварительно сжатыми файлами для приложений, так как они ожидают, что метод сжатия zip и порядок файлов будут такими, какие они выбрали. Я считаю, что открытые файлы .odf для офиса имеют эту проблему.

Тем не менее, если вы просто используете any-old-zip в качестве метода для хранения данных вместе, вы должны создать несколько простых псевдонимов, которые будут разархивированы и повторно застегнуты, если потребуется. Самый последний Msysgit (aka Git для Windows) теперь имеет как ZIP, так и unzip на стороне кода оболочки, поэтому вы можете использовать их в псевдонимах.

Проект, над которым я сейчас работаю, использует zips в качестве основного локального управления версиями/архивом, поэтому я также пытаюсь получить работоспособный набор псевдонимов для сосания этих сотен почтовых индексов в Git (и вынимая их снова;-), чтобы сотрудники были счастливы.