I already mentioned this tiny side project that I’ve been playing with a couple of time before. I learned a lot while working on it, so I realized I could share some of this knowledge around here. Let’s start with customizing the editor to use to write a commit message. This is probably obvious, but most of this blog post will talk about running git commands from your shell. If you’re not a command line user and prefer using some tool like Fork or Tower don’t be scared, it should be quite easy to follow.

Creating a commit with a pretty message

Making a commit from a terminal prompt happens through the git commit subcommand and accepts a number of parameters. The one that we won’t be interested in is -m. If you look at the command documentation, you’ll see that this is the argument that specify the message to associate to the commit.

Let’s assume we are working in a local repository with a README.md file in which we added some content.

To commit those changes, run git add README.md, then git commit from your terminal prompt:

git add README.md
git commit

Since we’re not using any of the options to pass the commit message that we covered earlier, git will open your default editor, letting you enter a commit message. In a lot of cases - especially if you haven’t customized your editor yet - it will open whichever editor available, like vi(m).

Finding the editor to use with git

There are a couple of ways to customize the editor to use with git: using environment variables and setting the core.editor git configuration key. If you’re not familiar with all the ways you can configure git, the official documentation is a good place to start.

If, after checking the GIT_EDITOR environement variable, then the core.editor configuration key, then the VISUAL environment variable and finally the EDITOR one, git is unable to find the editor to use, it will default to an editor depending on the platform, which is often vi. While that may seem unlikely because of the number of options, it’s actually the most common scenario.

Customizing the editor to use with git

The entire flow of opening an editor, waiting for the user to write the commit message then actually creating the commit is quite simple: it relies on files.

When you run the git commit command from your terminal prompt, git actually creates a temporary file named COMMIT_EDITMSG and invokes your editor with the path to this file as an argument. That means that when the editor is vim, the command executed is roughly something like vim /path/to/COMMIT_EDITMSG. Once you’ve edited that file and exited vim, Git reads the content of this file and uses it as the commit message.

It’s quite easy to experiment with the core.editor configuration without breaking your whole setup. You can pass it explicitly to the git subcommand that you’re running using the -c option, for example if you want to try using Visual Studio code, as covered in details in the documentation:

git -c core.editor="code --wait" commit

The most important information here is that git will invoke the editor, but it doesn’t have to be a program! While it’s often vim, emacs or Visual Studio Code, it can actually be anything as long as at the end of the invocation, the COMMIT_EDITMSG file contains the commit message to use! For example, it could be a bash function that always stores “WIP” as the commit message:

git -c core.editor=“echo WIP > $1” commit

Granted, this is kind of pointless, but it shows that this simple mechanism relying on files really lets you use any editor your want, as long as it provides a commit message at the end.

Photo by Pradipna Lodh