Repository structures for engine with submodules and multiple games using xlink

[BerkayDrsn]

Hi, we have a scenario where we have an engine repository that is xlinked to multiple submodules which are each repository themself. We are using Unity and the both project structure and repository structure looks like this:

(Engine Repository & Project)
-Assets
     -Engine
           -Core

(Engine Module #1 & Project)
-Assets
     -Engine
           -Core => Partial Xlinked to Engine/Core@Engine
           -Module #1

(Engine Module #2 & Project)
-Assets
     -Engine
           -Core => Partial Xlinked to Engine/Core@Engine
           -Module #2

This is the overall structure of the engine. Core Engine developers work in the first repository. Engine Module #1 developers work in the second repository and they need Core so it is xLinked. Engine Module #2 developers work in the third repository. They also need Core so it is xlinked. However Module #1 and Module #2 are independent so they don't xlink each other. 

Both Module #1 and Module #2 are actually big projects that lays the foundation of two independent game mechanics. However they are supposed to be used in the same game together. There can be more modules in the future. So imagine there is also Module #3 and Module #4 in the same structure.

Now comes the game part. Suppose that we have 2 games. 

(Game #1 Repository & Project)
-Assets
     -Engine
           -Core => Partial Xlinked to Engine/Core@Engine
           -Module #1 => Partial Xlinked to Engine/Module #1@EngineModule1
           -Module #2 => Partial Xlinked to Engine/Module #2@EngineModule2
    -Game #1

(Game #2 Repository & Project)
-Assets
     -Engine
           -Core => Partial Xlinked to Engine/Core@Engine
           -Module #1 => Partial Xlinked to Engine/Module #1@EngineModule1
           -Module #3 => Partial Xlinked to Engine/Module #3@EngineModule3
    -Game #2

So the Game #1 uses Engine with Module #1 and Module #2 however Game #2 uses Engine with Module #1 and Module #3. This is the overall structure we need right now.

As you see there are 5 teams right now.
Engine Team
Engine Module #1 Team
Engine Module #2 Team
Engine Module #3 Team
Game #1 Team
Game #2 Team

Now comes the question:

Suppose that you are an Engine Developer in Engine Team.
Your workspace is the Core folder. You receive a task from an issue tracker. That issue came for Game #1. You create a branch from main@Engine, now that repository doesn't have any xlink to the said game or the modules that game is dependent. So you xlink to them in your branch. That downloads those linked repositories from the server. However when you complete the task, you have to remove those xlinks so they don't go to main while merging. Now whenever you begin a task, you have to xlink the required repos, download them and remove them.

Problem:
Keep doing this "add xlink to sample game - do the task in branch - remove xlink from branch - merge to main" cycle is cumbersome for each task to do. Especially when downloading the sample game may take a lot of time if the game is huge. Also each task's sample game may differ. So you have to keep track of games and modules to xlink. Which is not feasible.

Expected Solution:
Local (or ignored) xlinks. If there would be a way to create xlink's locally (which creates an xlink in the current plastic workspace but doesn't checkin to the repository) that would fix our problem. So an Engine developer could create separate workspaces with each games dependencies but wouldn't checkin their xlink to engine repo. However there seems to be no way for that. (?) We don't want to keep changing xlinks in the Engine repo. That problem also happens in the Module developers. When you work in a module repo, what if you want to change the sample game you are testing the module? You shouldn't create an xlink in the Module repo targeting a game repo. You would have to keep changing it between the tasks. That is also a problem.

Any other approaches for the desired output?
 

[Héber]

Hi,

We are handling this request via zendesk.

Best,

Héber.