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 but not useful.
This looked like a neat idea, but, mentions that it’s only a proof-of-concept.
I came across this when I was preparing this post. It sounds attractive, but, it’s written in Python. Everything I’ve worked with in Python seems to;
- check if the correct version of Python is being used
- check for any other versions of Python
- silently throw toys from pram and refuses to start if there’s a wrong version
I’m not discussing proper-published projects; I’m discussing the half finished internal things from work. As an example; while Google’s TensorFlow plays nice from an Anaconda sandbox, the tool we wanted to rewrite in TensorFlow didn’t like Anaconda and didn’t want to start. In “If I have to fix it; it is broken” terms; I feel like being written in Python makes software inherently broken.
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.