Recommended release flow for multiple git-subtree repos

[Jason Karns <jason.karns@gmail.com>]

Hello!

Firstly, thank you all for your work on git-subtree. It has been a fantastic alternative to submodules for me.

I’m looking for some guidance on a recommended flow for a single parent repo with multiple subtree projects, assuming that the subtree projects _may_ have work directly in their repos, but most work for the subtrees will occur directly in the parent repo.

The project began with a single repo and the subprojects were extracted and created using `subtree split —rejoin` and `subtree push`. So at this point, all the subtree repos do share a common ancestor due via the rejoin merge commit.

My question is regarding future releases. (Releases will be done from a tag reachable from the parent’s master.) When I do a release, should I run only `subtree push` for each subtree? Doing so would keep the subtree repos HEADs at the correct place, but that will not change their merge-base with the parent repo, correct?

Alternatively, should I run `subtree split —rejoin` _AND THEN_ `subtree push` each release? I believe this would create a new “rejoin” merge commit for each subtree and therefore advance the common ancestor for the subtrees and parent repo?

Understanding that work in the subtrees would be rare means there would only rarely be a reason to `subtree pull/merge` any work from the subtree repos. Therefore, without a regular split-rejoin, the distance to a common ancestor would be ever-increasing. I suspect this would cause the subtree commands to take increasingly longer as they have more and more commits to replay each time?

Assuming that regularly running split—rejoin is a good way to mitigate this, is there a mechanism such that the rejoin merge commit can have multiple parents? (ie, merging all split subtrees into parent-master at once, instead of separate merge commits for each subtree)


Thank you so much for any insight you might be able to provide.

Regards,
Jason