bugfix: ensure we don't Wait() for subprocess twice

My previous patch introduced this problem. Run() is a combination
of Start() and Wait(), and I meant to switch the first Run() call into
Start() in my last patch (I even claim to have done so in the commit
message). I think this got messed up by a bad interactive rebase on my
part. Either way, this commit should prevent the program from panicking
due to a double-Wait().
bugfix: eliminate race reading from git ls-tree

This commit replaces the use of exec.Cmd.Run() with the use of both
exec.Cmd.Start() and exec.Cmd.Wait(). This is because Run() can close
the stdout pipe prematurely, and should not be used at the same time as
exec.Cmd.StdoutPipe() as per the docs here:


The result was that sometimes not all of the output of git ls-tree would
be parsed, and this led to many files which were actually present in the
git tree being ignored by the annotator. When this race is triggered,
the annotator usually provides no annotations whatsoever.

For an example of this race being triggered in the wild, see here:

Switch to less broken getopt implementation
Deal with weird git output
Add getopt options
Link up reverse references
Implement basic linking of references
Initial commit; basic AST dumper for research