Reputation: 7274
On a local machine, I have common scripts which are imported by several projects, e.g.:
/common/
.git/
scripts/
common1.py
/projectA/
.git/
scripts/
A1.py (imports from common1.py)
/projectB/
.git/
scripts/
B1.py (imports from common1.py)
Common scripts and projects are tracked in separate git repos. This works fine for my personal work because I can clone all repos needed. When making a project publically available via git, I can include common files via subtrees or submodules (references to common files are updated in B1.py obviously):
/projectB/
.git/
scripts/
common/ (subtree from common)
common1.py
B1.py
Now I'd like to assemble a superproject (the target):
/projectC/
.git/
scripts/
common1.py
A1.py
B1.py
With subtrees and submodules I've been able to achieve:
/projectC/
.git/
scripts/
common/
common1.py
projectA_scripts/ (via subtree)
A1.py
common/ (via subtree w/in projectA)
common1.py
projectB_scripts/ (via subtree)
B1.py
common/ (via subtree w/in projectB)
common1.py
C1.py
However this is quite redundant and propagating changes through the sub-x chain will be tedious. How can I achieve the target directory structure above while retaining the ability to pull updates to project and common files? For what it's worth I don't expect to need to push subtree/submodule changes upstream.
Bonus for cross-platform (Windows-UNIX) solutions that don't require independent configuration on both OS's. Git-based solutions preferable.
Upvotes: 4
Views: 795
Reputation: 1329082
Since you don't have to push those subtree/submodule content back, you could consider symlink those folders into common/
:
Upvotes: 2