Consider subtrees instead of submodules

[stub42]

Git has two standard ways of embedding a branch inside another branch: submodules and subtrees.

submodules embed a reference to the embedded branch. The command 'git submodule update' needs to be run to prepare the branch for use.

subtrees embed a copy of the embedded branch. A freshly cloned branch does not need to be prepared for use; it already contains a complete copy of all the embedded dependencies.

For our use case of embedding the operator framework and other shared charm dependencies in charms, subtrees seem preferable. The charm using subtrees can be cloned an immediately deployed. Deployment tools such as juju-deployer and mojo do not need to be taught about the new branch 'prepare' stage that is replacing the reactive charm 'build' stage. Deployments from the charm store are unaffected either way, so this really only affects charm developers and sites needing to deploy directly from branches.

[relaxdiego]

Just adding some arguments and counter-arguments via this explanation of subtrees: https://www.atlassian.com/git/tutorials/git-subtree

[jameinel]

There is nothing in the operator framework that mandates one over the other. We chose submodules because it doesn't vendor the code directly into the parent tree, and it makes it cleaner to have patches to a subproject while waiting for upstream to respond. (You have your own branch of the code, with a proper commit history that doesn't mix the history of the parent project with the submodule.) You can still do "git clone --recurse-submodules" from the beginning, and it will check out the entire tree. However, you do need to realize that submodules are being used.

[stub42]

The choice made in examples and documentation will be the template for many projects. If it expected that branches will need submodules expanded before deployment, we will need to teach the CI and deployment systems to expand submodules how to do that. A choice made by individual developers doesn't change this - if I have a single charm that needs submodules expanded before deployment, then my CI & deployment pipeline is going to need to cope with that.

I think we can go with either. Off the top of my head, I think we are looking at minor updates to implicitly expand submodules to codetree, juju-deployer, mojo, and maybe juju if bundles can reference a git branch. Jenkins jobs and similar will need tweaking anyway.

[stub42]

Lets close this, sticking with submodules because seem to be more widely known about. Deployment tools dealing with branches can be updated to use git clone --recurse-submodules.