Git альтернатива субмодуля?

У меня есть пара рабочих деревьев с некоторыми зависимостями. AFAIK, подмодуль git обеспечит следующее:

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

Я не возражаю против увеличения объема репозиториев, но наличие копий для меня совершенно неприемлемо. Это заставит меня реорганизовать все проекты, чтобы копия была связана. Более того, редактирование неправильного файла может легко произойти, что приведет к путанице.

У меня есть другая идея:

  • Каждый мастер хранит список всех своих подчиненных устройств.
  • Никакой другой информации в мастер не требуется.
  • С каждой фиксацией в master создается моментальный снимок" в подчиненном устройстве.
  • "snapshot-commit" - это моментальный снимок текущего состояния рабочего дерева, он игнорирует текущее состояние индекса (я уже использую "моментальные снимки", прежде чем отбрасывать некоторые неуправляемые изменения).
  • "моментальные снимки" собираются в ветке, чье имя происходит от имени мастера. Сообщение фиксации содержит хэш главной фиксации. (ИМХО, это лучше, чем наводнение тысячами тегов.)
  • Проверка выполняется, как обычно, если не требуется рекурсия в ведомые устройства.

Единственные проблемы, которые я вижу, следующие:

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

Я спрашиваю, кто-то уже реализовал это (или если это плохая идея).

ОТВЕТЫ

Ответ 1

Я думаю, что это плохая идея, потому что это странно, и это приведет вас к поддерживаемому пути для многих вещей.

Сначала пояснение: при использовании подмодулей репозиторий "master" (referencing) не становится заметно большим. Он хранит только ссылку на репозиторий (вероятно, URL) и идентификатор фиксации. Но это не похоже на то, что нужно.

При работе с такой проблемой есть три основных пути: вы можете спуститься вниз:

  • Поместите все в один репозиторий. Вы убеждали себя в 10 раз, что вам действительно нужно отделять вещи? Помните, что вы можете начать с одного репо и разделить его позже. Также помните, что git слияние фактически работает, поэтому разработчик не является проблемой.

  • Использовать внешнюю систему управления пакетами. git НЕ, и не претендует на роль менеджера пакетов. Коэффициенты хороши тем, что используемая вами платформа имеет диспетчер пакетов, который поддерживает более сложные ситуации зависимости. Maven, rubygems, npm, nuget... их много.

  • Использовать подмодули в подкаталогах.

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

Ответ 2

Я не уверен, что я слежу за вами, поскольку родительский репо (ваш "хозяин" ) хранит только ссылку на жесткий SHA1 подмодуля (субрепо проверочно в родительском репо).
Размер родительского репо не затрагивается вообще.

стратегия слияния поддерева (лучше управляется, хотя git поддерево) увеличит размер родительского репо, но это (сложение поддерева) - это не то, о чем вы говорите.

Другой альтернативой подмодулю будет git -slave (gits), что немного похоже на то, что вы хотите реализовать.