Image created on Picture to People

Git-Config: core.editor

Interact with Git’s Files and Commands in Your Favorite Text Editor

https://pragprog.com/newsletter/

One key to leveling up your Git game is to configure Git’s core.editor setting to reference the text editor that you’re happiest using.

Plenty of workaday Git activity takes place right on the command line: passing configuration values into git config, or writing commit messages with the -m flag after git commit. But sometimes it’s desirable or even necessary to command Git via a text file edited from within a text editor. Configuring Git to use the editor that you’re comfortable using is the gateway to writing more elaborate commit messages, manually editing patches for commit with git add -e, and even rewriting your repo’s history with git rebase -i.

On most systems, Git defaults to vi, vim, or another command-line editor. Here’s Darth Vader’s Git configuration file opened in the terminal editor vi after running the command git config --global --edit:

The Git config file in vi. Don’t panic: hit `Esc` and then type `:q!` to exit from this nightmare.

That default is probably fine for anyone familiar with or willing to learn a command-line editor. But if you prefer to get on with your work in a different text editor, you can configure Git to use your preferred editor instead.

💡 Tip: Hitting ESCfollowed by typing :q! gets you out of editors like vi.

Launch Your Editor from the Command Line

Git will happily work with most standalone graphical editors, such as VS Code, Sublime Text, BBEdit, and many others. The only catch is that your editor must be capable of launching from the command line. Some editors require you to install specific tools to gain that functionality. Read your editor’s friendly manual, or run a quick Google search for the name of your editor and “open from terminal” to get yourself pointed in the right direction.

Whether installing tools is necessary or not, you can always run a quick sanity check to make sure your editor’s terminal command is in your path. Here’s an example with BBEdit:

$ which bbedit
/usr/local/bin/bbedit

If your command-line returns a “not found” message when you run which, you’ll need to double-check that you’ve in fact installed your editor’s terminal commands (or the editor itself!) and that your $PATH variable includes the path, like /usr/local/bin in the example above, where the editor’s terminal commands can be found.

Setting a Wait Option

The terminal command alone is rarely enough for Git, though: graphical editors often must be launched by Git using an option like --wait, sometimes shorthanded to -w like on Sublime Text. Those “wait” options keep Git from prematurely finishing a command while you’re still working on a Git file.

If you’re uncertain about required options for your preferred editor, another Google search for its name and “Git core.editor” should help. The Git Community Book maintains a list of popular editors and how they can be configured to work with Git, but do check with your editor’s documentation to make sure you’re passing in the correct switch.

Once you’ve confirmed that your editor’s executable is in your path and discovered the necessary switches or flags required for opening your editor from Git, the final step is to let Git know to use your editor of choice via git config. If you’re a VS Code user, for example, you can set core.editor to take VS Code’s code command with its --wait switch:

$ git config --global core.editor "code --wait"

After you’ve configured core.editor to your liking, you’ll find that any command that triggers Git to open an editor will now open in your editor of choice. Here is the same git config --global --edit example as above, but now with Vader’s configuration file opened in the macOS text editor Nova:

Editing the .gitconfig file directly in a graphical editor.

While your file remains open, your command line will display the message “hint: Waiting for your editor to close the file…” That message disappears as soon as you’ve saved and closed the file, leaving Git to execute your commands as expressed in the file.

Correct Typos in Your Commits

With Git’s core.editor variable now configured, you can confidently run git commit without any arguments and write your commit directly in your favorite editor. That change will enable you to go beyond subject-line-style commit messages and write manifesto-length bodies for your commits as well.

And even if you opt to write your original commit message on the command line with the -m flag, you’ll now find it very easy to fix pesky, inevitable typos by running git commit --amend. First, let’s introduce a goof:

$ git commit -m "Udpate known rebel base locations"

Oops. Let’s fix that “Udpate”:

$ git commit --amend

That will now open the commit in your preferred editor:

The calming comfort of editing commit messages within your editor of choice.

Once you correct “Udpate” to “Update,” save the file and quit. You can then inspect the history of the changed commit back on the command line:

Amended commits change your repo’s history—and save you from embarrassment.

Note that a changed commit message leads to a changed commit hash, so be sure to think twice about editing commit messages for any commits you’ve already pushed to a public remote.

Commit messages might be the most obvious and embarrassing place to make typos in Git, but other typos will slow things down when you’re running Git commands themselves. In the next post, we’ll look at different reasons for configuring Git with your own custom aliases—including wiring up your own idiosyncratic typos to run the Git commands you intend.

Karl Stolley

Karl’s book, Programming WebRTC: Build Real-Time Streaming Applications for the Web, is available in beta from The Pragmatic Bookshelf. You can save 35 percent with promo code git_config_2022 now through October 15, 2022. Promo codes are not valid on prior purchases.

Programming WebRTC