When editing source code using gvim (v.7.4.488), I want to commit some changes the vcs (I'm using git 2.1.4 from the command line in Ubuntu linux).

git --status

shows which files I changed. However, it also shows the vim .*.swp of the currently visible buffer(s) (both if the file contain unsaved changes and when the edited file is the same as the .*.swp-file). Ofcourse, git can ignore these files or vim can store the swap files in a different location (see vim.wikia or this question at stackoverflow). But I like the .*.swp-files showing up in git --status when they contain unsaved changes, since it signals me that I'm committing files in a different state than what I think they are in.

How can I avoid the false positives of .*.swp-files showing up in git --status when the saved file is the same as the .*.swp-file, while being able to see that file to commit are in a different state than the ones I'm editing with vim?

  • Is it possible to only have .*.swp-files, when file on disk and file in vim are different?
  • Is there an other way to detect unsaved files?

Combining the comments of @elyashiv and @VanLaser results in a simpler method than detecting whether swap files imply unsaved files:

  1. do not let git ignore the .*.sw[po] files;
  2. when committing, if git --status reveals any .*.sw[po]-files do a :wa in vi; and,
  3. add and commit.
  • 1
    you can use :wa to make sure there aren't any unsaved files.
    – elyashiv
    Commented Aug 9, 2015 at 14:06
  • 2
    really, it's much "saner" to make sure all your files are saved before you git commit ...
    – VanLaser
    Commented Aug 9, 2015 at 16:29

2 Answers 2


vim -r at the command line will list all swap files in the current directory and temporary directories, and whether they contain any unsaved changes. Look for the line that says modified: no/YES.

I don’t know how to tell Vim to look in a different directory, so you’ll need to change to each directory that contains a swap file and run vim -r. You could come up with a script that parsed the output of git status, or used find -name '.*.sw[po]', and then ran vim -r in each directory, to show all swap files with unsaved changes.

(I use .*.sw[po] instead of .*.swp, because sometimes .swo files are created in addition to .swp files, when you edit a file that already has a swap file. .swn files can be created too if you edit a file with two existing swap files, but I don’t think I’ve ever seen one in the wild. If you’re really paranoid, you could use .*.sw[a-p] or simply .*.sw?.)

See :help -r for (a little) more information on the -r option, or :help recover.txt for more information on recovery and swap filenames.

  • 1
    Well, Vim's swap files are hidden files (leading . in the filename) so the right pattern would be .*.sw[a-p] (although in pathological cases, you could actually get all the way to .foo.saa). That should also preclude matching Flash files, since I doubt those would typically be a hidden file.
    – jamessan
    Commented Aug 10, 2015 at 18:33
  • @jamessan The leading . is required in a shell glob, but *.swp works as an argument to find. But the leading . makes things simpler. Thanks!
    – Lithis
    Commented Aug 10, 2015 at 18:47
  • Is it possible to only have .*.swp-files, when file on disk and file in vim are different?

Yes. The snippet below (adapted from tpope's vimrc) will disable the swap file for a buffer when it isn't modified, so swap files only exist for modified files.

autocmd CursorHold,BufWritePost,BufReadPost,BufLeave *
  \ if isdirectory(expand("<amatch>:h")) | let &swapfile = &modified | endif

Caveat: Since the swap file only exists when the buffer is modified, you lose the use of the swap file as an advisory lock. If the buffer is unmodified, then another Vim can start editing it without notice that it's already open. If the second Vim saves before the first one makes more changes, then they won't be noticed until the user tries to save or something triggers Vim to check if the file is modified.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.