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

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

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

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

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

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

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

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

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

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

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

Спасибо, гляну.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мейнтейнеры пакета с этой либой

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

Побежал.

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

Зависимости и супер-репозитории.

в репе ОС эта либа ужасно старая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем спасибо за объяснения, вы мне очень помогли.

//от использования подмодулей пока воздержусь

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

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

Ни в каких, ибо это ад.

Использовать адекватный ЯП.

не лезь,она тебя сожрет

но тогда почему не монорепа?

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

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

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

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

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

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

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

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

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

Так удобнее.

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

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

Использую submodules, когда мне бывает нужно натянуть сову на глобус.

шоры сними - скриптовые компилять не надо.

т.е. апгрейд дистра на боевом серваке - это пц?

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

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

притягивает внешние исходники которые могут быть уже 100500 раз измененны

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

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

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

Да, когда этот проект используется в больше 1 твоих. Часто это нафиг не надо и удобнее и надёжнее притянуть срез в каталожик завимисомтей и не париться.

Но, дело хозяйское, если удобно кому то, то без вопросов.

Офигенно удобно. Класс. Если зависимости от 15 либ, то мы будем клонировать все их сорцы со всей историей изменений. А если их разрабатывали долго и упорно, то это прям песня. Особенно, если тебе надо просто собрать ПО, а не разрабатывать.

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

Например притащить gl4es как сабмодуль и статически слинковать его с рендерером можно, а вот притаскивать SDL2 смысла нет. Последний скорее всего есть в репозиториях дистрибутива и он относительно стабилен, когда как у gl4es что не коммит – регрессия.

Спасибо за некропост. Родина тебя не забудет!

Хихи, а какого фига оно у меня тогда в трекере вылезло? В любом случае пожалуйста!1!

UDP: Ааааа, это анон оживл, потом хобит его почистил. Невиноватая я он сам пришёл!"

Освой опцию –depth

Это всё замечательно. Тут –depth не забудь указать. Здесь git-submodule update сделать после каждого git-checkout/git-bisect в основном проекте. Для зависимостей, которые не в git, городи отдельные костыли. Очень удобно.