Okay, progress at last! I'm trying to balance between contributor reach-out, general organization, and actually doing some work myself. Finally attached the module split-out to the point where something visible.
I've got Git commands that'll extract a module out of the current code base into its own repo on GitHub. It maintains commit history in the new repo which is important IMHO to keep attribution. Here's
Portals in its own home (under the Nanoware test org). Wonder if could make "mod.txt" into a README that'll get displayed on GitHub yet still be parseable for the info we need.
Likewise we can fully remove the modules from the main code base including all history - beyond just doing a delete. I'm not sure that's really a good idea after testing it though, as doing it rewrites
every single commit ever which beyond taking a while also splits a new branch into its own thing. You can see that on the network branch right now or on the Nanoware
branches page - after removing Portals the "rewritten" branch is 2,225 commits ahead and 2,165 commits behind
If you scroll back on the network graph you can see both MovingBlocks and Nanoware contain roughly the same history, especially back before much was done for Portals. Oddly enough the two constructs
do converge, but waaaay before we ever had modules, like only a dozen or two commits from the founding (they split in an ancient commit from
begla about the light system, no clue why)
In addition to that I've got Gradle working with
Git tasks and automatically cloning remote repos based on a passed parameter. Supports picking the organization/user as well, so modules could be fetched from different spots. Needs more work though. In addition to cloning the repo the module should also be configured as a sub module in IntelliJ like they currently do, and would independently maintain their own Git roots
My suggestion is that when
Immortius is happy with the multiplayer branch we break off the modules and either finish deleting them in that branch or rewrite history to get rid of them. Then any non-module changes in develop we can consider bringing over manually. Or maybe we can do it early and get modules to work fully externally first. Will keep tinkering with it - for now I need sleep!