Hello, future me. This is for you next time you want to do this.

When setting up the CI for a project I will sometimes end up with a tremendous clutter of workflow runs. Sometimes they have embarrassing mistakes. Who wants to show that to people? I was trying to figure out how to bulk delete workflow runs from the CLI, and I came up with something that works:

gh run list --json databaseId  -q '.[].databaseId' |
  xargs -IID gh api \
    "repos/$(gh repo view --json nameWithOwner -q .nameWithOwner)/actions/runs/ID" \
    -X DELETE

This will delete all (well, up to 20, or whatever you set in --limit) your workflow runs. You can add flags to gh run list to filter runs by workflow or by triggering user.

I sometimes find myself writing articles or documentation about git, so I put together a couple of terrible hacks for generating reproducible histories and pretty graphs of those histories.

git synth

The git synth command reads a YAML description of a repository and executes the necessary commands to reproduce that history. It allows you set the name and email address of the author and committer as well as static date, so you every time you generate the repository you can identical commit ids.

While working on a pull request I will make liberal use of git rebase to clean up a series of commits: squashing typos, re-ordering changes for logical clarity, and so forth. But there are some times when all I want to do is change a commit message somewhere down the stack, and I was wondering if I had any options for doing that without reaching for git rebase.

It turns out the answer is “yes”, as long as you have a linear history.

You’re working on a pull request. You’ve been working on a pull request for a while, and due to lack of sleep or inebriation you’ve been merging changes into your feature branch rather than rebasing. You now have a pull request that looks like this (I’ve marked merge commits with the text [merge]):

7e181479 Adds methods for widget sales
0487162 [merge] Merge remote-tracking branch 'origin/master' into my_feature
76ee81c [merge] Merge branch 'my_feature' of https://github.com/my_user_name/widgets into my_feature
981aab4 Adds api for the widget service.
b048836 Includes fixes suggested by reviewer.
3dd0c22 adds changes requested by reviewer
5891db2 [merge] fixing merge conflicts
2e226e4 fixes suggestions given by the reviewer
da1e85c Adds gadget related API spec
c555cc1 Adds doodad related API spec
e5beb3e Adds api for update and delete of widgets
c43bade Adds api for creating widgets
deaa962 Adds all get methods for listing widgets
9de79ab Adds api for showing a widget and simple data model
8288ab1 Adds api framework for widget service

You know that’s a mess, so you try to fix it by running git rebase -i master and squashing everything together…and you find yourself stuck in an endless maze of merge conflicts. There has to be a better way!

Always work on a branch (never commit on master)

When working with an upstream codebase, always make your changes on a feature branch rather than your local master branch. This will make it easier to keep your local master branch current with respect to upstream, and can help avoid situations in which you accidentally overwrite your local changes or introduce unnecessary merge commits into your history.

Rebase instead of merge

If you need to incorporate changes from the upstream master branch in the feature branch on which you are currently doing, bring in those changes using git rebase rather than git merge. This process will generally start by ensuring that your local copy of the upstream master is current:

It’s a bit of an embarrassment when you submit a review to Gerrit only to have it fail CI checks immediately because of something as simple as a syntax error or pep8 failure that you should have caught yourself before submitting…but you forgot to run your validations before submitting the change.

In many cases you can alleviate this through the use of the git pre-commit hook, which will run every time you commit changes locally. You can have the hook run tox or whatever tool your project uses for validation on every commit. This works okay for simple cases, but if the validation takes more than a couple of seconds the delay can be disruptive to the flow of your work.

This is a small collection of simple git tips and tricks I use to make my life easier.

Quickly amend an existing commit with new files

I have this alias in place that will amend the current commit while automatically re-using the existing commit message:

alias.fix=commit --amend -C HEAD

With this in place, fixing a review becomes:

$ vim some/file/somewhere
$ git add -u
$ git fix

Which I find much more convenient than git commit --amend, following by saving the commit message.

This post is in response to a comment someone made on irc earlier today:

[I] would really like a git lookaside cache which operated on an upstream repo, but pulled objects locally when they’re available

In this post I present a proof-of-concept solution to this request. Please note that thisand isn’t something that has actually been used or tested anywhere!

If you access a git repository via ssh, it’s easy to provide a wrapper for git operations via the command= option in an authorized_keys file. We can take advantage of this to update a a local “cache” repository prior to responding to a clone/pull/etc. operation.

Someone named hithard on StackOverflow was trying to clone a git repository via https, and was running into an odd error: “Cannot communicate securely with peer: no common encryption algorithm(s).”. This was due to the fact that the server (openhatch.org) was configured to use a cipher suite that was not supported by default in the underlying SSL library (which could be either OpenSSL or NSS, depending on how git was built).

Many applications allow the user to configure an explicit list of ciphers to consider when negotiating a secure connection. For example, curl has the CURLOPT_SSL_CIPHER_LIST option. This turns out to be especially relevant because git relies on libcurl for all of its http operations, which means all we need to do is (a) create a new configuration option for git, and then (b) pass that value through to libcurl.

This is a terrible hack. If you are easily offended by bad ideas implemented poorly, move along!

You are working on a wonderful open source project…but you are not supposed to be working on that project! You’re supposed to be doing your real work! Unfortunately, your extra-curricular activity is well documented in the git history of your project for all to see:

And now your boss knows why the TPS reports are late. You need workinghours, a terrible utility for doing awful things to your repository history. Workinghours will programatically time shift your git commits so that they appear to have happened within specified time intervals (for example, “between 7PM and midnight”).