git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Recommended release flow for multiple git-subtree repos
@ 2020-03-22 18:49 Jason Karns
  0 siblings, 0 replies; only message in thread
From: Jason Karns @ 2020-03-22 18:49 UTC (permalink / raw)
  To: apenwarr, git

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-03-22 18:49 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-22 18:49 Recommended release flow for multiple git-subtree repos Jason Karns

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).