Re: git-submodule getting submodules from the parent repository

Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> writes:

It's not just racy, but I think it's wrong to limit to _one_ branch in each submodule..

A submodule is an independent project on its own.

Suppose the commit DAG in the submodule looked like this:

                 o---o
                /     \
     --o---o---o---o---o---X---o---Z
            \                 /
             o---o---o---o---o---o
                  \     /
                   o---o

and the superproject points at commit X. You may need to tweak the submodule to make it work better with the change you are making to the superproject.

You have two choices:

 (1) update to some "stable" branch head that is descendant of X first,
     and make sure it works with the superproject.  Then develop on top of
     it, and bind the tip of suc development trail to the superproject:

                 o---o
                /     \
     --o---o---o---o---o---X---o---Z---o---o---Y (your changes are Z..Y)
            \                 /
             o---o---o---o---o---o
                  \     /
                   o---o

I think this is what you are suggesting. But the superproject may not be ready to use the submodule with the history from the lower side branch merged in. You would

 (2) fork off of X and develop; bind the tip of such development trail to
     the superproject.  IOW, you make the submodule DAG like this, and
     then "git add" commit Y in superproject.

                 o---o       o---o---Y (your changes)
                /     \     /
     --o---o---o---o---o---X---o---Z
            \                 /
             o---o---o---o---o---o
                  \     /
                   o---o

Sometimes forked branches need to be maintained until it proves stable (and then your "tip" Y may be merged back to the tip of a public branch Z). So you would at least need to allow a set of topic branches in submodules that corresponds to a single lineage of superproject history.

Then when both Z (with the changes from the lower side branch) and Y (your changes) prove stable, the submodule project may decide to make a merge between Y and Z.

                 o---o       o---o---Y (your changes)
                /     \     /         \
     --o---o---o---o---o---X---o---Z---W
            \                 /
             o---o---o---o---o---o
                  \     /
                   o---o

The superproject may decide to "git add" the result of such a merge, but that decision is done separately (and obviously after such a merge is made).

If everybody involved in the superproject forked from whatever happened to be bound to the superproject, however, the submodule will have uncontrolled number of unmerged "tips". For the submodule to stay viable as an independent project, some management has to be done to clean up this mess. To manage the forked development inside submodule properly, I do not think you can autocruise from the toplevel superproject and leave the random branches or unnamed commits unmerged.

That is why I suggested to:

 * Leave the HEAD in submodule detached, if you are not working in it;

 * Have a project policy regarding the use of branches in the submodule.
   When you need to work on submodule, first switch to the branch (the
   policy may allow/encourage you to create a new topic branch here), and
   commit to it.

 * The policy should also say when these forked branches should be merged;
   keep them tidy by following that policy.

And by pushing from submodule and then in toplevel, you will never have "superproject names a commit unreachable from any of the branch tips of submodules" problem. Nor there is any raciness issue -- only after you push out the submodule successfully, you push out the toplevel (and if the former fails, you may need to redo the toplevel commit, but that happens before you push it out so you can afford to rebase or amend).