1

I am building a system with a foundation (You may call it a boilerplate or a framework) because the system need to be customized to deliver among many clients based on their specified requirement especially for look and feel and user experiences. So I need to create two repositories for my project. First one is a base repository contains ground level part for the foundation. The second one is the project specific repository which contains upper level part.

I'm looking for a solution to allow me to only have to open a project directory in a single workplace and can edit entire project inseparately. But after commit and push them, they go to different specific repository. One at a time git commands is acceptable.

If using git submodule add, I can link from a parent repository to a child repository, so two project repositories may share and maintain the same sub-repository from their own sub-directory. But what I need is reversed from that. Projects do not among them share a common child repository but a common parent repository. Are there any Git's feature provided enable me to do that? Or any workaround either with Git or on client side? Or any way I can do it with submodule but may restructure it later on client side?

What have I tried

I can't find any solution yet using submodule. Not directly but I've managed to pull from multiple remotes and merge them, solved half of my problem. But still finding out how to select which files going to which remote on push.

stackunderflow
  • 1,492
  • 1
  • 23
  • 53
  • Umm, I am unsure if I understood your question correcty, but I think you just create a project=root with multiple submodules which "use" your root project. – wederer May 19 '20 at 13:30
  • @wederer you bet – stackunderflow May 19 '20 at 17:11
  • Does each client need to track which version of the parent is used, so that updates to the parent don't break clients? – TamaMcGlinn Sep 16 '20 at 08:12
  • Does the answer need to work on ancient systems that don't support symlinking directories, such as Windows? [(workarounds exist, but are messy)](https://stackoverflow.com/questions/5917249/git-symlinks-in-windows) – TamaMcGlinn Sep 16 '20 at 08:28
  • Couldn't you just have the clients be forks of your framework? That would make it pretty straightforward to rebase them onto new versions, although you would need some filter-branch-ing to get any changes to the framework done in the clients back into the main framework repository. – TamaMcGlinn Sep 16 '20 at 08:38
  • @TamaMcGlinn Yes. So far that's how I'm doing. The only issue in is project repo contains everything from base repo which I just assume I can't simply exclude them. For versioning and tracking actually not that needed in my case and I do it manually – stackunderflow Sep 27 '20 at 08:32
  • Actually it's just push to and pull from a single local directory from and to different repositories is what I need – stackunderflow Sep 27 '20 at 08:35
  • ah; perhaps you need [multigit](https://github.com/capr/multigit)? – TamaMcGlinn Sep 28 '20 at 12:48

1 Answers1

1

If your superproject (the root project in proper git nomenclature) never changes, but the submodules do, you should manage this in two environments: development and building.

There is no way of doing what you need from git and version every combination. Typically, the superproject includes the submodule, not the other way around.

Probably, the best alternative (and here is speculation) is to include all submodules in the root, and use pre-processor directives to instruct the compiler about which submodules are to be compiled each time.

If that is not an option, you should at least review your architecture, or go on and use other technologies. With vanilla git, you can try to load and unload modules directly from the development machines.

Another option is to define clone macros to generate each working tree dynamically (clone superproject, add submodule X, deploy on machine for development), you can achieve this via any bash/batch scripting.

Daemon Painter
  • 3,208
  • 3
  • 29
  • 44