Git edit - improving --fixup

I’m a big fan of attempting to make my git history useful. This often means reworking my commits so that work is done in a sensible order and in small logical units. There are many ways to rework your history in git but one I’ve used a lot for the past year is the --fixup flag when committing. This has often led to annoying problems, in this post I’ll look at:

Using --fixup

The --fixup flag is a bit like the --amend flag except you can specify the commit you want to squash your work into rather than it just being squashed into the most recent commit.

When given the following history:

* 0230dcb (HEAD -> master) Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

If I stage some changes and run git commit --amend then the last commit Add git-edit post will be rewritten to include my staged changes.

If instead I want my changes to go into a commit that is not the most recent then I can use the following command git commit --fixup 4564152. In this example I would end up with the following

* a5f2563 (HEAD -> master) fixup! Add testing tips post
* 0230dcb Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

Once I have this I can run git rebase --interactive 9051216 and accept the todo list to have git squash the new changes into the target commit.

Problems with --fixup

I love --fixup but it doesn’t quite do so well when you have heavy churn in your files (possibly a sign that the work could be reordered). The issue you run into a lot is that when you make your changes to fix up a commit you are potentially looking at a source file that has been changed in multiple steps. Any changes you make may only make sense in the current state of the file, this can lead to conflicts when targeting an earlier revision of the file.

A solution git-edit

We can avoid the issues above by:

This is achievable by using our friend git rebase --interactive <commitish>. Going back to our earlier example

* 0230dcb (HEAD -> master) Add git-edit post
* 4564152 Add testing tips post
* 9051216 Add tying things together post

If I want to make changes to the commit 4564152 then I can run git rebase --interactive 4564152~1 to be presented with a todo-list in an editor.







I can now change the first pick line (which is for the commit we passed in) to say edit instead e.g.

- pick·4564152·Add·testing·tips·post¬
+ edit 4564152·Add·testing·tips·post

After saving this file I’ll be placed on the commit 4564152 where I can make my edits, add changes and finish up by calling git rebase --continue.

The above is fine but it’s a little manual so it would be nice if we could automate away some of these steps. Let’s see how we can do that.

Creating your own git commands

The first piece of the puzzle is creating a git command. I’d like the command to work as if it was a git subcommand by typing git edit <commitish>. This is actually not too difficult to do - add an executable command somewhere on your path with the name git-edit. Now when I call git edit <commitish> git will invoke my script. Let’s test it


echo "hey"


> git edit aabbcc


The next challenge is how do I automate editing the todo list that you get when you call git edit? Again git has a nice seam for us to work with - we can set the environment variable for GIT_SEQUENCE_EDITOR to our own command. Our command will be invoked with one argument, the path to the todo-list file.

With this knowledge we can write a script that will:

Let’s do this in ruby:

#!/usr/bin/env ruby

  exec "GIT_SEQUENCE_EDITOR='#{__FILE__}' git rebase --interactive #{ARGV.first}~1"

todo_list = ARGV.first

lines = File.readlines(todo_list)
  .take_while { |line| line != "\n" }
  .map        { |line| line.gsub("fixup", "pick") }

lines[0] = lines[0].gsub("pick", "edit")

File.write(todo_list, lines.join)

With all of this in place we can now run a git subcommand that automates the process of rewinding us back to a particular commit to allow us to make changes and then reapply all subsequent commits in order.


There’s a few handy things to take away here around adding your own scripts to git. Knowing that it’s actually not too painful to add quite complex automation means that I’ll really pay attention more to manual tasks that I repeat and look at automating these tasks in future.