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
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