What is better to use for a multi-module project: subtree or submodule?

Question

git

I am writing a multi-module project in C++. Prior to that, I inserted the source code of dependency modules directly into the source code of the module for which these dependencies were described (copy-paste, I was too lazy to bother with Git jokes for this). Recently I realized that this does not work and you need to organize everything in a human way, through some mechanism provided by the git.
I read about submodules, but then I came across this article and this article . It said that there is such a thing - subtree - which is much cooler than submodules. I read it, and a suspicion arose that it was not entirely correct to compare these mechanisms, they simply have different areas of application.
Actually, the question is whether subtree is really a universal replacement for submodule, which is better than it for any tasks, or is there cases when submodule is better.

Confused thoughts about

Дисклеймер: Я пока не очень хорошо разбираюсь в git - буквально второй день - поэтому тут может быть бред.
Среди главных преимуществ subtree по отношению к submodule указывается, в частности, отсутствие необходимости выполнять специальный апдейт новых версий зависимости (апдейт во время исполнения команды pull для внешнего репозитория).
Исходя из этого, как я понимаю, механизм submodule был рассчитан на использование в проектах, для которых переход на новую версию зависимости означает серьёзные изменения в самом проекте (например, новая версия меняет программный интерфейс, что может привести к поломке компилирования кода проекта). В контексте изоляция зависимости от pull-а внешнего проекта для submodule это не баг, а фич - фича, позволяющая более строго контролировать версии зависимостей на машинах всех коммитеров проекта. Другой вопрос, конечно, почему нельзя при каждом пуле внешнего проекта автоматически смотреть не пришло ли обновление версии зависимости в рамках заданной в .gitsubmodule - но это отдельная тема.
Механизм subtree же используется для таких зависимостей, у которых каждый коммит не вносит серьёзных изменений в работу внешнего проекта, либо для внешнего проекта в приоритете стоит необходимость гонки за последними фичами зависимостей.

updated: Discussion continued

Answer 1

The first article you cited (from 2009) does not talk about git subtree, but about subtree merge strategy. The second one is correct. The only thing I don’t do is I don’t define subtree as a remote, so that there are no extra “tails” from subprojects in any Git Extension.
Further, since any subproject update via subtree pull is done manually, and not automatically, I do not understand your last statement. Finally, the developer made a new version of his module (a long series of commits), then made a new branch in the main project, pulled his final changes there, checked that everything works, and can merge into the main branch. Or what kind of workflow do you have? And the developers of the main module do not even need to know about the subtree. Here is a subdirectory with a (changed) plugin - so use it. There are problems - discuss with its developer.
PS And read about the "rake" with the submodule - the link in the second article...
Just written

Answer 2

One more opinion . Coincides with my view of things - submodule to work in a repo outside our area of ​​responsibility, subtree - for bidirectional communication.
update: Another discussion on the topic.

Answer 3

It is better to use a dependency management system. For example Apache Ivy or similar. It is believed that subtree and even more so submodule are simplified and limited in functionality replacements for normal dependency management systems. Here is a good description of the problems associated with using ... .
Using Ivy implies having a project build system. But the possibilities for managing dependencies are unlimited. It is especially nice when you have a team of more than 2-3 people, 2-3 dozen libraries and you need to support and develop several versions of the application at the same time.
Although Ivy is written in Java and is very tightly integrated into the Java world, it is a generic dependency manager and we used it to manage dependencies in a C# project.
Perhaps there is something special for C++, but I am far from this world.