Marshalling Gits

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.

Peter LaValle avatar
About Peter LaValle
honks at geese. speaks the byzantine languages that make the magic boxes do the things. Someday maybe I'll retire and be a graphics programmer or demoscene coder.
comments powered by Disqus