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.

---

submodule

Git’s (somewhat) anointed solution is “submodules” and comes built in. Google’s CORGI project (et al) use it.

trial

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.

subtree

https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

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.

sub-repo

http://www.mos6581.org/git_subtree_alternative

This looked like a neat idea, but, mentions that it’s only a proof-of-concept.

BONUS; quack

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.

Conclusion

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.