Automatically wrap long Git commit messages in Vim

GitVimWord WrapCommit Message

Git Problem Overview


Using Git, my editor for commits is Vim. I'm constantly doing a poor job of remembering to wrap lines and so I get long lines (see this answer for example). Is there a way using some git config or .vimrc magic that I can get Vim to automatically wrap lines at 72 columns?

Related question.

Git Solutions


Solution 1 - Git

Add this to your .vimrc:

au FileType gitcommit setlocal tw=72

Solution 2 - Git

Add this to your .vimrc:

filetype indent plugin on

From here.

Solution 3 - Git

While the other answers solve this problem perfectly well, I highly recommend you install Tim Pope's fugitive.vim.

fugitive.vim is an excellent plugin that brings Git functionality to Vim. It has a whole host of features that aren't relevant to your question, but are worth checking out. However, it can also help you remember to keep your commit messages the proper length:

Sample commit message within Vim on fugitive

Solution 4 - Git

2018 Update - Update vim

If you update vim, it will automatically highlight the first 50 characters of your title and wrap lines at 72 characters. It knows that you're editing a git commit file.


Mac users can use Homebrew:

brew install vim

If you still aren't seeing the syntax highlighting, make sure you have it enabled:

> You need to have following settings in .vimrc file as per arch linux > documentation > > filetype plugin on > syntax on

Solution 5 - Git

In addition to other answers, use gqip to reformat a paragraph while editing.

See Vim Tips Wiki: Automatic formatting of paragraphs

Solution 6 - Git

Here's a git hook for auto-wrapping that will work with any editor: https://github.com/surabhigupta/AutoWrapSeventyTwo

Solution 7 - Git

Several of the options from the earlier posts work, except I noticed inconsistencies between different systems.

Fedora 28 (recently upgraded from F26) was easy once I realised :version inside git-commit/git-tag showed it was pointing to .virc files (weird*) so I simply copied my ~/.vimrc into ~/.virc [except, see below].

macOS 10.13.4 with vim 8.0 from brew works just fine off /usr/share/vim/vim80/ftplugin/gitcommit.vim according to :verbose :set tw=?.

CentOS 7.4 with vim 7.4 (git version 1.8.3.1) for some reason though didn't appear to be making use of the textwidth line in its supplied gitcommit.vim so I went for a quick and dirty workaround (to save me from dealing with multiple files) in ~/.vimrc:

nmap <F2> :set textwidth=72<CR>
inoremap <F2> <Esc>:set textwidth=72<CR>a

That seems to work well enough and is easy to remember - I mostly only pull from there anyway and have kind of given up messing around any more with the old versions of git and vim.

Otherwise, I (temporarily) went for Chip Hogg's suggestion after Abe Voelker's answer: autocmd FileType gitcommit setlocal textwidth=72

I don't think it makes much of a difference inside git-commit but it's possibly better to be safe (especially if that line ends up getting copied throughout a vimrc). Filetype is of course set to on, as it is in many example vimrcs.

* However, I was still curious as to why vim's ruler wasn't showing, so I looked at :help ruler which informs +cmdline_info (displayed after :version) needs to be set at compile time. Running :ver in vim outside of git-commit revealed different settings and a different compiled time, suggesting that git was perhaps calling the system copy of vim instead of the user one.

So what I should have done at the beginning to all this was run git config --global core.editor "vim" except I didn't because I had assumed it was a redundant step. Doing this first on every git installation might save a lot of hassle from the start!

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionmgilsonView Question on Stackoverflow
Solution 1 - GitAbe VoelkerView Answer on Stackoverflow
Solution 2 - GitAlexView Answer on Stackoverflow
Solution 3 - GitDavid CainView Answer on Stackoverflow
Solution 4 - GitJBallinView Answer on Stackoverflow
Solution 5 - GitcambunctiousView Answer on Stackoverflow
Solution 6 - GitsurView Answer on Stackoverflow
Solution 7 - GitRaymond Wu WonView Answer on Stackoverflow