Git submodule

Использую, описанных проблем либо не встречал, либо встретил один раз, починил и забыл

А сколько еще людей работают совместно над этими исходниками?

Использую, сейчас очень нравится, т.к. вкурил. По-началу бесило. Были написаны даже скрипты,что бы избежать использования сабмодулей. Но потом оказалось, что сабы - меньшее из зол. Ссылка правильная у тебя, сам всегда использую https://git-scm.com/book/en/v2/Git-Tools-Submodules как шпаргалку

Вопрос был не мне, но в тех проектах, о которых я говорю - это человек 50 программистов, активных разработчиков и тысячи пользователей , делающие «clone-make-run»

Давно использую. Проблем особо нет, брат жив.

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

Использовал, технических проблем не встречал никаких. Пожалуй, это единственный допустимый способ включения в проект стороннего кода (в отличие от subtree, загрязняющего как репозиторий так и историю, и простого commit чужого кода, также загрязнающего репозиторий, а истонию теряющего). Все подводные камни лежат вне плоскости git, а в плоскости opensource экосистемы. Если у вас не опенсорс проект, можете дальше не читать и смело использовать сабмодули. Для остальных:

Начнём с того что включение чужого кода это почти всегда bad practice. Либо проект один, тогда один реп, либо проектов несколько, тогда они должны, по логике, разрабатываться независимо.

На практике же случается что это действительно нужно или удобно:

• Пара foo и foo-data. Разрабатываются совместно, но при этом не везде хочется таскать тяжёлую -data (например, в CI)
• Форкнутый сторонний код со своими значительными изменениями, которые нельзя заапстримить (например, наполовину переписанный движок)
• Модульное, но сильно связанное приложение (foo-daemon, foo-cli, foo-gui использующие общую foo-lib). Дополнительный балл если foo-lib используется в чужих проектах
• Лёгкие (header-only либы) и/или слабораспространённые зависимости
• Опциональные данные, например данные для тестов. Тут да - у submodule нет ни минусов, ни альтернатив.

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

Ещё подводный камень - невозможность скачать проект одним tarball'ом с GitHub. Для мантейнера это лишняя головная боль (хотя CI может собрать tarball с исходниками и всеми данными сразу).

Коммит в проект это вообще за гранью добра и зла :)

У нас закрытый проект и есть некоторое кол-во питоновских модулей (а может и не только питоновских в песпективе) которые в разных микросервисах должны быть общими. Сейчас выбираю простой и грамотный способ пихать эти модули в докер при обычном docker build так, чтобы у всех членов команды оно гарантированно сработало без шаманств.

Справедливости ради, немного

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

невозможность скачать проект одним tarball'ом с GitHub. Для мантейнера это лишняя головная боль

А использовать гитхабовские тарболлы в качестве релизных - это вообще ССЗБ, так как они генерятся на лету с минимальной компрессией

Без докера костылей было бы в разы больше, так что это меньшее из зол для нас.

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

Это не ССЗБ, а распространённая практика, альтернатив-то которой по сути нет (гитом скачивать? нет, спасибо). Они доступны сразу, а килобайтом больше/меньше - никого не волнует.

Практика показала что править библиотеки и набор проектов которые их используют проще используя ссылки чем субмодули. Это касается тех случаев когда библиотеки правят вместе с проектами которые их используют. Особенно неудобно когда несколько библиотек и несколько проектов которые от них зависят. Кроме того библиотеки надо скачивать отдельной командой. С другой стороны, проект может быть привязан к конкретным версиям библиотек и не сломается при дальнейших правках библиотек когда меняется API. Я практиковал оба варианта(с субмодулями и с загрузкой библиотек отдельно), и там и там есть преимущества и недостатки. Если библиотеки не правишь, а только используешь, то субмодули однозначно предпочтительней. Если код правится в нескольких местах одновременно, это приводит к ряду неудобств. Решается временным удалением субмодулей и заменой их на ссылки(в итоге всёравно надо будет вернуть субмодули и закоммитить их новые версии).

альтернатив-то которой по сути нет

приличные люди выкладывают тарболлы для релизов

Юзаю, описанные проблемы «проблемы» собственно проблем не доставляли. Проблемой было то, что когда надо пошарить доступ к репозиторию, надо ещё и шарить доступ к репозиториям сабмодулей (которые могут разрабатываться другими командами), а когда этих сабмодулей целая древовидная пачка, ух!

Учитывая что гитхаб делает тарболлы чего угодно сам, а также что autocrap канул в Лету и теперь не нужно поверх содержимого репозитория нагенеривать мегабайты шеллового мусора чтобы им можно было пользоваться (ага, а потом фанаты autocrap говорят что де он самодостаточный, а для cmake сборки нужен cmake, ужас-ужас), приличные люди привыкли на бесполезную работу время не тратить и тарболлами не заморачиваться. Но да, в редких случаях использования сабмодулей хороший тон таки собрать самодостаточный архив.