tl;dr; I'm starting a new "side-project". (I say side-project in quotation marks because I'm doing this for the sake of work ultimately). It's call gg and it's a command line program for doing various tasks to do with git, GitHub and Bugzilla.
Many years ago I noticed certain patterns of things I do. Usually work starts with a Bugzilla bug. I then need to make a new branch with the bug number in the branch name and when I'm done I need to push that branch to my fork and create a GitHub Pull Request. When it's been merged (or if I merge it manually myself) I have to go back to the master branch, fetch the upstream, delete the now merged branch and delete the remove branch. All of these things are tedious so I wrapped up my patterns in a little Python project called bgg, so I can do:
$ G start 123456789 # that's a bugzilla ID # edit files and save $ G commit # now I wait for the Pull Request to be merged $ G getback # all things get cleaned up and I'm back on the master branch
This new project,
gg, is a complete re-write of
but with some big changes:
So far, I've only written 1 plugin. It's called gg-start. All it does is it creates branches for you. For example, you can type:
$ gg start https://github.com/org/repo/issues/1234 # or... $ gg start https://bugzilla.mozilla.org/show_bug.cgi?id=123456789 # or... $ gg start
And it figures out a good branch name, remembers the issue title and checks out the new branch. All that stuff is saved in
~/.gg.json so that when you later (and this plugin hasn't been built yet) type
gg commit it can use that title to automatically suggest a good git commit message and it should know where to push it and start the GitHub Pull Request etc.
My intention is to first get decent parity with
bgg. So I'll need to create plugins called
gg-push. Once parity is achieved I'm going to add some more fancy features and work hard on making it clear how you can write your own plugin.
Wish me luck!