This is a quick post-mortem on the three methods I examined for nesting some of our Git repos. In the end, I ran out of time and felt that the diversity of a CS team means that special handling would not produce a time saving benefit for me.
Git’s (somewhat) anointed solution is “submodules” and comes built in. Google’s CORGI project (et al) use it.
I created two shared repositories and a third master repository. While submodules seemed to work at first (and showed up pretty on GitBucket) they required extra commands to work right.
Looks dead - not sure how to install it? Seems to be a tool for weaving history trees together or apart; I find this attractive if not useful.
This looked like a neat idea, but, was only mentioned as a proof-of-concept.
I came across this when I was preparing this post. It sounds attractive, but, everything I’ve worked with in Python seems to;
- check if the correct version of Python is being used
- refuse to start if the wrong version is installed
- check for any other versions of Python
- silently throw toys from pram without telling anyone if other versions are found
In “If I have to fix it then it is broken” terms; I feel like being written in Python makes software inherently broken.
Google’s TensorFlow plays nice from an Anaconda sandbox; everything else I’ve used breaks out somehow and silently crashes.
I really need a hands-off solution, and, these are not it. I found that I was able to achieve most of what I wanted by hard-coding various gubbins into CMakeLists. Going forward … I’m hoping that CGC will be working well enough to alleviate theses concerns.