Using the Skara Tooling

I’m writing this for myself as much as I’m writing this to share. After only a day of using JMC with Skara, I’ve fallen in love with it. I spend less time painstakingly putting together review e-mails, copying and pasting code to comment on certain lines of code, cloning separate repos to do parallel work efficiently, setting up new workspaces for the these repos etc. Props to the Skara team for saving me time by cutting out a big chunk of the stuff not related to coding and a whole lot of ceremony.

Note that the Skara tooling can be used outside of the scope of OpenJDK – git sync alone is a good reason for why everyone who wants to reduce ceremony can benefit from the Skara tooling.

So, here are a few tips on how to get started:

1. Clone Skara:
   git clone https://github.com/openjdk/skara
2. Build it:
   gradlew (win) or sh gradlew (mac/linux)
3. Install it:
   git config --global include.path "%CD%/skara.gitconfig" (win) or git config --global include.path "$PWD/skara.gitconfig" (mac/linux)
4. Set where to sync your forks from:
   git config --global sync.from upstream

For folks on Red Hat distros, 2 and 3 can be replaced by make install. For more information on the installation, see the Skara wiki.

Some Examples

To sync your fork with upstream and pull the changes:
git sync --pull

Note: if the sync fails with the error message “No remote provided to fetch from, please set the –from flag”, remember to set the remote for your repo, e.g.
git remote add upstream https://github.com/openjdk/jmc

To list the open PRs:
git pr list

To create a PR:
git pr create

To push your committed changes in your branch to your fork, creating the remote branch:
git publish

JMC Workflow

Below is the typical work-flow for JMC.

First ensure that you have a fork of JMC. Either fork it on github.com, or on the command line:
git fork https://github.com/openjdk/jmc jmc

You typically just create that one fork and stick with it.

1. (Optional) Sync up your fork with upstream:
   git sync --pull
2. Create a branch to work on, with a name you pick, typically related to the work you plan on doing:
   git checkout –b <branchname>
3. Make your changes / fix your bug / add amazing stuff
4. (Optional) Run jcheck locally:
   git jcheck local
5. Push your changes to the new branch on your fork:
   git publish (which is pretty much git push --set-upstream origin <branchname>)
6. Create the PR, either on GitHub, or from the command line:
   git pr create

Summary / TL;DR

• I ❤️ Skara