Design

Mostly for me to think about how it should be.

Code design

main - basically a bridge between a console and the actual logic.
- Defines command-line interface (i.e. subcommands, arguments etc).
- Injects real dependencies into gitopolis module
lib - top of re-usable gitopolis module, pulls in all modules it needs (everything except main basically)
gitopolis - all the logic of this tool.
- injected dependencies:
  - state storage trait
  - git operations trait
  - stdout - not injected yet but, this needs to change to return programatically useful responses instead of piles of strings in byte form
exec - run arbitrary commands in list of paths/repos
- currently a separate thing managed by main, needs to be controlled by gitopolis.rs instead
- writes to stdout, not streamed, also needs to change
repos - models for encapsulating state of repo(s) with methods for changing state
- needs a bit of tlc, currently exposes its Vec<Repo> internals, but otherwise seems sound

End-to-end, uses all the code for real, what's mocked and simulated tbc but should be testing maximum breadth of code. This is the one to give confidence that a PR hasn't completely broken it in a way the more granular tests don't catch, e.g. someone breaking the arg parser.
gitopolis_tests - tests just the main logic in the library, with mocked storage, git (& stdout?). Faster and more granular than end-to-end.

Currently using logging (info! macro etc) with custom formatting. Not sure this is wise.