Как git хранить дубликаты файлов?

У нас есть репозиторий Git, содержащий входные данные и результаты SVM AI. Каждый раз, когда мы запускаем новую модель, мы создаем новую корневую папку для этой модели, чтобы мы могли организовать наши результаты с течением времени:

/run1.0
  /data
    ... 100 mb of data
  /classification.csv
  /results.csv
  ...
/run2.0
  /data
    ... 200 mb of data (including run1.0/data)
  /classification.csv
  /results.csv
  ...

По мере создания новых моделей мы можем извлекать данные (большие .wav файлы) из предыдущего запуска. Это означает, что наша папка данных 2.0 может содержать все файлы из 1.0/data плюс дополнительные данные, которые мы могли собрать.

Репо легко будет превышать Gigabyte, если мы сохраним это.

Есть ли способ Git распознавать повторяющиеся двоичные файлы и хранить их только один раз (например, как символическая ссылка)? Если нет, мы будем перерабатывать, как хранятся данные.

Ответы

Ответ 1

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

ob064b56112cc80495ba59e2ef63ffc9e9ef0c77

Он будет храниться как:

.git/объекты/OB/064b56112cc80495ba59e2ef63ffc9e9ef0c77

Первые два символа используются как имя каталога, а остальные - как имя файла.

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

Ответ 2

По умолчанию/сам: Нет Да.

Git работает на том основании, что он создает моментальные снимки файлов, а не инкрементные различия, как и другие VCS.

ИЗМЕНИТЬ

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

... несколько файлов с одним и тем же содержимым сохраняются только один раз.

Также обратите внимание, что, как упоминалось в этом ответе, концептуально...

Ссылка на git -scm documentation:

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

Однако на уровне хранения все еще используются дельта, в которых git пытается как можно быстрее создать минимально возможную дельта на основе эвристического выбора blobs, есть опции, которые оптимизируются для сжатия. Это уменьшит размеры репозитория.

Также, как проверено opatut в pastebin link выходов из комментариев, дублирующие объекты хранятся только один раз. Это означает, что git распознает повторяющиеся двоичные файлы и сохранит их только один раз. Это был вопрос, который задавал первоначальный вопрос. Ниже перечислены другие способы обработки дубликатов файлов.

Другая альтернатива: Символы

Вы можете настроить символические ссылки на предыдущие файлы, таким образом, при работе над ними они укажут на один и тот же большой файл, однако обратите внимание, что Git не отслеживает файлы, которые символические ссылки указывают на, то есть они будут только хранить символическую ссылку. Это удовлетворяет вашей потребности в сокращении пространства, при жертвоприношении переносимости, то есть, если вы перейдете на другую машину Dev, вам нужно убедиться, что файлы указаны там, где указаны символические ссылки. Это может быть не то, что вы хотите. См. этот очень хороший SO Q & A о том, что git делает для символических ссылок.

Еще одна альтернатива: инструменты!

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

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

Или встроенный git-submodules и отдельный репо для достижения того, чего вы хотите, где вы только извлекаете большие двоичные файлы, чтобы их использовать.

По общему признанию, я не пытаюсь использовать эти параметры, поэтому здесь приведена ссылка, чтобы прочитать больше объяснений о них. Ссылка: этот вопрос SO

Ответ 3

Даже если git сохраняет файлы, которые сохраняют вас на вашем пути, чтобы сделать что-то, вы используете неисправный VCS и теряете все преимущества использования VCS, не имея возможности увидеть, какие изменения сделано между 2 версиями.

Вам лучше иметь каталог "run" с вашими файлами и делать фиксацию для каждой новой версии (даже с тегами, если вы хотите более легко увидеть ваши важные "прогоны" ).

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

Не нужно держать все в подсолнухах!

То, что вы пытаетесь сделать, это плохо!