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 but not useful.


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.


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.

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