I'm opening this issue to fulfill a few purposes:

• Aggregate all merge related commits
• As a guideline and checklist on what should be done
• Documenting the process in case anything goes wrong in the future
• Providing a draft to comment on before the merge

So I'll be referencing this issue in each related commit and I will update this post as I go.

The process

Preparation

• Open a CurseForge project for each module

Merging

• Visit each 1.11 module branch and git mv anything specific to this module to its new place
  • Branch 1.11-base: EnderIO Base
    • {1.11-base}:/src -> enderio-base/src
    • {1.11-base}:/doc -> enderio-base/doc
    • {1.11-base}:/resources -> enderio-base/src/main/resources
  • Branch 1.11-machines: EnderIO Machines
    • {1.11-machines}:/src -> enderio-machines/src
    • {1.11-machines}:/doc -> enderio-machines/doc
    • {1.11-machines}:/resources -> enderio-machines/src/main/resources
  • Branch 1.11-conduits: EnderIO Conduits
    • {1.11-conduits}:/src -> enderio-conduits/src
    • {1.11-conduits}:/doc -> enderio-conduits/doc
    • {1.11-conduits}:/resources -> enderio-conduits/src/main/resources
  • Branch 1.11-invpanel: EnderIO InvPanel
    • {1.11-invpanel}:/src -> enderio-invpanel/src
    • {1.11-invpanel}:/doc -> enderio-invpanel/doc
    • {1.11-invpanel}:/resources -> enderio-invpanel/src/main/resources

Notes: Only use git mv manually moving stuff will break git blame and history in general.
Probably should do this is in temporary branches, to bot clobber the old ones (i.e. chackout 1.11-base and immediately branch out to 1.11-base-merge).

• Checkout 1.11-base-merge, we'll start from here.
• Delete the git submodule for CoFHLib, it will cause problems when merging, we'll add it later.
• Start merging the 3 other branches (machines, conduits and invpanel)
  • Resolve any possible conflict before the merge, any conflict will fail the octo-merge.
  • Merge with octopus strategy (thanks @tterrag1098).
  • If there are any conflicts (with the ours strategy there shouldn't be) resolve them favoring the current branch (ours).
• Add back the CoFHLib git submodule

Notes: We merge with the ours strategy because all conflicting file will be overwritten anyway to support the new multi-project configuration. Since it doesn't matter I chose ours.
We use merge with no-ff instead of (1) rebase squash - it doesn't make sense to squash the entire history of a project (each module is practically a project), (2) merge --ff there are going too be conflicts so fast forward probably won't work and with such a colossal merge I feel a merge commit is in order.

Configuration

• In gradle.settings - add an include statement for each of the modules.
• In gradle.settings' - change rootProject.nametoenderio`
• In gradle.properties - add the following (global) entries:
  • minecraft_version = target minecraft version (1.11.2)
  • mcp_mappings = target mappings snapshot (TBD)
  • forge_version = target forge version (TBD)
  • version_major = major version of the mod (4)
  • version_minor = minor version of the mod (0)
  • version_patch = patch version of the mod (TBD)
  • version_appendix = release state of the mod (alpha?)
  • all relevant dependencies versions
• For each module, add a gradle.properties file with the following entries:
  • module_name = the (public) name of the module (without 'enderio')
  • module_build_number = the build number of the module
  • curse_projectId = the project id for the module
• For each module with dependencies and a gradle.properties file describing both internal and external dependencies.
• Configure build.gradle

Build enhancements

• Add a 'gradle.user.properties' file for user specific settings
• Add gradle.user.properties to .gitignore

gradle.user.properties can be used for settings such as userLocalEnderCore

Future work

• Add the eclipse and idea plugins to integrate with IDEs better
• Add GitVersion or similar integration

Looks good, just a couple of details:

• While at it, move resources to src/main/resources (and adapt build.gradle)
• doc can be a top level directory, we don't need multiple copies. It's basically a dump for stuff we want to keep but that doesn't go into the build.

• Will do
• I remember seeing different items on each branch. Any strategy I should use when merging? I see only 1.11-base is updated

The docs in anything but base are untouched since the submod split, so they can simply be thrown away before merging. (I actually thought I'd done that already, at least for machines...)