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
Peter is currently a PhD student at the University of Nottingham. His day work involves applying functional programming to problems with artificial intelligence. Someday maybe he'll retire and be a graphics programmer or demoscene coder.
comments powered by Disqus