a single directory containing git submodule and parent repository

Question

Use case: We have a directory containing IDE configurations of which some should be shared over a set of projects and some which are project specific. This means some parts of the config directory must be shared with the project while some should come from a centralized source.

Since Project is a git repository I considered using git submodules to solve this. As far as I understand if I make config a submodule I have to share project specific 1 & project specific 2 via that submodule. The alternative would to make shared 1 and shared 2 individual submodules. The git book didn't help me to find a solution.

Questions:

• Is there a way to have one submodule or other construct which contains shared1 & shared2 while project specific 1 & project specific 2 are still part of the Project git repo?
• If so, how does a solution look like?
• If not is the approach flawed (and how) or am I just out of luck?

Edit 1:

In repsponse to @Mark Adelsberger : The files we are talking about are not runtime configurations but configurations for the IDE. Thus trying to solve this in the build phase is not expedient.

Edit 2:

I was following the hint of @Thomas with symbolic links. I created a submodule sharedConfig containing shared1 & shared2 which was placed in project and then have two sym-links in config which target the directories in sharedConfig . Sadly the IDE im using does not follow the sym-links but crashes. If you use a more mature tool this might be a solution for you.

Edit 3:

After all I tried I agree with @Mark Adelsberger , there is no way to do what I intended although there are workarounds/hacks which might work for some platform/tool combination. In the end I went with having each shared# directory as a separate submodule.

Answer 1

I know of no way for a submodule to share a directory with the parent repo[1].

You could use multiple modules, and could even have them share the same physical repo (by using different branches for each module); but I think that would get inconvenient pretty quickly.

If the config files are used at runtime, then it may be sufficient to use a build process that moves the files to the correct location where they'll be needed at runtime. In that way your source control work tree structure doesn't have to match what you've shown above, and a lot of options open up for how to share the code[2]. You could use submodules, or (IMO even better) you could package the config files separately (as a (npm|maven|nuget|whatever's-appropriate-for-your-technology-stack) artifact to be used as a dependency by the projects that need it.

If the config files are used at development time (and if the dev tools insist that they be in particular locations), that's a little trickier - but still can be managed by moving files around after checkout. This could be scripted and even automated using hooks (or possibly some functionality of your IDE or other development tools). In that case, you might want the parent repo to .gitignore the config/shared* directories.

---

[1] While it might be clear how this should work in your use case, in general it would introduce a lot of questions, and the answers would at best result in some counterintuitive behaviors. (If the parent and submodule TREE objects that share the directory both have an entry for the same filename, what happens? If a new file is added to the working directory, which repo is it added to (or how do you specify which)?

[2] Contrary to advice in the comments, I think a mono-repo is one of the worst ways for projects to share code. It's far more likely to cause problems than to solve them.