LINUX.ORG.RU

В каких случаях вы используете git submodules?

Когда нужно зависеть от другой репы. Особенно когда это нужно в нескольких репах.

Например есть либа, которая используется в нескольких проектах, и чтобы не дублировать код этой либы в этих проектах, её проще вывести в отдельную репу и в репах, которые зависят от этой либы, сделать сабмодули.

Из попенсорца можешь посмотреть на QMK, который тянет lufa, который используется ещё и в TMK.

mord0d ★★★ ()

Когда в проекте есть подпроекты разрабатываемые в отдельном цикле разработки / другой командой. Ну или вот как выше комментом написали. В остальном - ненужный адский геморрой.

SkyMaverick ★★ ()
Ответ на: комментарий от mord0d

её проще вывести в отдельную репу и…

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

по моему опыту, сабмодули - боль и страдания.

aol ★★★★★ ()

Если не уверен, что тебе нужны подмодули, тогда они тебе не нужны. Инфа 146%. А вот когда у тебя будет задача и ты будешь искать пути ее решения, тогда и можно рассмотреть подмодули как вариант организации репы. Но пока задачи нет, не стоит их тащить в репу.

yetanother ()

типичные случаи когда вы поимели от этого профит, ну и подводные камни

Профит один - отдельная история. Подводный камень, собственно, тоже один - --recursive есть не у всех команд.

В целом, я за позицию @yetanother

anonymous ()
Ответ на: комментарий от mord0d

Например есть либа, которая используется в нескольких проектах, и чтобы не дублировать код этой либы в этих проектах, её проще вывести в отдельную репу и в репах, которые зависят от этой либы, сделать сабмодули

Что не даст ровно ничего - и подмодуль отдельно тянуть надо в каждую репу, и собирается оно тоже в каждой репе отдельно. Лол. Единственный способ «не дублировать» - это установка на хост + написание нормальной сборки(которая сначала ищет на хосте и собирает либу только если не нашло). Остальные маня-способы не работают.

anonymous ()
Ответ на: комментарий от Egor_

а как ещё включить в свой проект чужую либу

Как угодно. Начиная от коммита сорцов либы в основную репу(в отдельном подгаталоге, например) и заканчивая загрузкой с гитхаба во временный каталог в процессе сборки. Сабмодули со «статической компиляцией» никак не связаны(как и со сборкой в целом).

anonymous ()

типичные случаи когда вы поимели от этого профит,

Это правильный выбор глагола. Подмодули в гите поимеют тебя в 100% случаев. Я не знаю ни одной задачи, которую нельзя было б решить другим способом. Все проблемы со сборкой и зависимостями должны решаться в CI/CD системе, иначе это костыли и геморрой.

cocucka ★★★ ()
Ответ на: комментарий от anonymous

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

а кто будет следить за обновлениями чужой либы и регулярно менять код «в отдельном каталоге» на актуальный? пушкин?

подмодули для того и придуманы, чтобы упростить этот процесс

Egor_ ()
Ответ на: комментарий от Egor_

а кто будет следить за обновлениями чужой либы и регулярно коммитить новую актуальную версию «в подмодуль»? пушкин?

Побежал.

К тому же, никто кроме бездарностей на локалхосте не делает «регулярное обновление» на актуальную версию. Под это создаётся отдельная задача, обновляется код либы, проводится тестирование. Очевидно, ни один вменяемый человек не будет проделывать такое только для «актуализации». Оправдываться.

anonymous ()
Ответ на: комментарий от anonymous

К тому же, никто кроме бездарностей на локалхосте не делает «регулярное обновление» на актуальную версию. Под это создаётся отдельная задача, обновляется код либы, проводится тестирование.

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

а кто будет следить за обновлениями чужой либы и регулярно коммитить новую актуальную версию «в подмодуль»?

git submodule update будет следить
а ты продолжай велосипедить с временной папочкой для скачивания с гитхаба перед компиляцией )))

Egor_ ()

некоторые зависимости так прописываю. Используется конкретный коммит и ничего не ломается в случае, когда эти зависимости обновляются

SR_team ★★★★ ()

Использую только в сборочных скриптах.

типичные случаи когда вы поимели от этого профит

Когда один проект разнесён на несколько репозиториев по соображениям удобства, всё обновляется синхронно и без конфликтов. В этом случае можно не заморачиваться с пакетированием зависимостей, достаточно сделать что-то типа git submodule update --init --recursive --remote. Так сильно меньше геморроя с лишними сущностями.

подводные камни

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

WitcherGeralt ★★ ()

Использую если решил ограничиться Makefile, но есть некоторые зависимости, которых уж точно нет в репозиториях.

Вообще, meson применяет что-то похожее: клонирует недостающие зависимости из их репозиториев git и собирает.

ArkaDOSik ★★ ()
Последнее исправление: ArkaDOSik (всего исправлений: 1)

Я активно пользовался.

Собственно, есть два условия для использования submodules:

  • Один и тот же код используется в нескольких проектах.
  • Над этим кодом активно ведется работа в рамках вашей команды/компании.

Переиспользуемые части лучше постараться как-то между собой объединить в один логический сабмодуль, т.к. когда сабмодулей много - это адище. У нас, к примеру, было три:

  • Система сборки.
  • Ядро.
  • Юзерспейс.

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

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

Из плюшек - легко шарить между проектами новые баги фичи и исправления. Производительность труда выросла в разы.

cherry_boy ()
Последнее исправление: cherry_boy (всего исправлений: 1)

Для встраивания кода модулей в дерево основного проекта.

Сейчас использую в основном для того, чтобы в dotfiles загружать vim-плагины в bundle. Больше ни для чего не пригодилось.

E ★★★ ()

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

Rastafarra ★★★★ ()
Ответ на: комментарий от Rastafarra

Потому, что монорепа — замечательно в прямых руках, но ужас в кривых. https://yosefk.com/blog/dont-ask-if-a-monorepo-is-good-for-you-ask-if-youre-good-enough-for-a-monorepo.html

А набор из раздельных репозиториев одинаково убог независимо от прямости рук.

x3al ★★★★★ ()

В каких случаях вы используете git submodules?

Ни в каких. Используем много отдельных реп. Зависимости между репами разруливаем самодельным менеджером пакетов.

yvv ★★☆ ()
Ответ на: комментарий от Egor_

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от Egor_

а кто будет следить за обновлениями чужой либы и регулярно менять код «в отдельном каталоге» на актуальный? пушкин?

А кто будет это с сабмодулями делать? тянуть актуальный «мастер» с чужого репозитория - это тоже не самая лучшая идея.

Dudraug ★★★★★ ()
Ответ на: комментарий от Rastafarra

Так удобнее.

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

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

cherry_boy ()

активно использую при зависимостях от сторонних модулей. все просто и удобно. не удобно неосиляторам. главный плюс что коммит внешнего модуля фиксируется и если внешний модуль уйдет вперед и у него например смениться API - это никак не повлияет

quester ★★ ()