Jonathan Tan <jonathanta...@google.com> writes: > What if, in the submodule, we have a new ref backend that mirrors the > superproject? When initializing the submodule, its original refs are not > cloned at all, but instead virtual refs are used. > ... > These rules seem straightforward to me (although I have been working > with Git for a while, so perhaps I'm not the best judge), and I think > leads to a good workflow, as discussed below.
Indeed this is intriguing. > The above rules allow the following workflow: > - "checkout --recurse-submodules" the branch you want on the > superproject > - make whatever changes you want in each submodule > - commit each individual submodule (which updates the index of the > superproject), then commit the superproject (we can introduce a > commit --recurse-submodules to make this more convenient) The "recurse" option would also give users an extra atomicity, and would not be merely for convenience; when a user wants to treat a superproject and its two submodules as if the combined whole were a single repository, there shouldn't be two separate commits in the history of the superproject only because two submodules made one commit each to work on a single theme that spans all of them.
