Stefan Beller <sbeller@xxxxxxxxxx> writes: >> - We have to make separate commits and manage corresponding topic >> branches for the superproject and subprojects. > > Well yeah, that is how submodule work on a conceptual level. > While having multiple commits may seem like overhead, note > the subtle difference for these commits. One if deep down in the > stack patching one of the submodules, the other is a high level > commit advancing the submodule pointer. > > Note that the target audience of these two commit messages > might be vastly different, hence can be worded differently. > (The submodule describing how you fixed e.g. a memleak or race condition > and the superproject describes on why you needed to include that submodule, > e.g. because you switched your toplevel application to use threads.) Both good points. Another thing to keep in mind is that in a well-organized project, it is expected that you would have multiple commits in a submodule, solving one single issue that is needed by the superproject in a finer grained way, before the resulting submodule tip is recorded in the tree of the superproject in one commit. IOW, between the time the superproject's history moves by one commit, the submodule may have multiple commits in order for the submodule to become ready to be consumed by the superproject.