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

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

11 голосов
/ 16 июля 2011

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

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

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

У меня есть еще одна идея:

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

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

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

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

Ответы [ 2 ]

11 голосов
/ 02 августа 2012

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

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

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

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

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

  3. Использовать подмодули «смонтированные» в подкаталогах.

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

2 голосов
/ 18 июля 2011

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

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

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

...