On 27/10/16 09:59, Junio C Hamano wrote:
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.
I'm a relatively new user of submodules and I quite like them (having
tried a few other strategies for sharing common code between multiple
projects and found them quite painful) and find them fairly easy to use.
I especially like the fact that the submodule command isn't very
complicated and that the best method for managing commits, etc in the
submodule is to cd into their root directory and then treat them like
any other git repository (greatly reducing the amount of new stuff that
you have to learn in order to use them). Also, from my experience so
far, I see three different types of work going on within my workspaces
that include submodules:
1. I'm working on changes to the submodule and using the superproject
that it's checked out in to test those changes in which case most of the
change is occurring in the submodule with changes in the superproject
usually being small one related to API changes in the submodule.
2. I'm working on changes in the superproject and the only changes that
get made in the submodules are to fix bugs uncovered by the work in the
superproject.
3. I'm modifying a superproject to accommodate changes to a submodule
that's changed as a result of having changes pulled from another repository.
In none of these cases do I feel the desire/need to commit the changes
to the superproject and submodule(s) with a single commit command which
more or less agrees with your points.
However, for git commands such as diff/status whose job is to display
information it would be nice if they had a --recursive option to
override the default submodule diff/status and show details of the
changes in the submodules. Sometimes you want to see the big picture in
detail.