Putting your Vim files under version control

If you are like me – a computer nomad, roaming from one machine to another throughout the day – you should put your Vim configuration files under source control. Cause, you are using vim, right? If you are not using vim, then just mentally substitute the word “Emacs” wherever you see “vim” or “vi”. The principles are more or less the same.

My vim files are currently on Github and I finally set everything up so that this single repository can be easily shared by different platforms. Previously I had separate setup for Windows, Linux and Mac and it was driving me crazy. So I went through all of them, threw up stuff I never used or needed, and consolidated them into a single profile that is now portable.

Step number one to accomplish this is to put your .vimrc inside your .vim directory. The directory is where Vim stores all kinds of files – color schemes, plugins, etc.. It is a natural place to create a repository. The problem is that the main config vile .vimrc lies outside of it, smack dab in the middle of your home dir. That file must be tracked as well. So we just move it into .vim and create a soft link in ~.

On Linux and Mac you accomplish it like this:

mv .vimrc .vim/.vimrc
ln -s .vim/.vimrc .vimrc

Now create a git repository inside, and boom! You are golden!

What about Windows? Windows sucks. For whatever reason, the window port of the one true editor uses different naming convention: _vimrc for the config file and vimfiles for the directory. These files are located in your %USERPROFILE% directory.

How do we take our Linux config and port it to Windows? First let’s delete the current config and clone our repository:

rmdir /s /q vimfiles
del _vimrc
git clone path/to/your/.vim.git

Now you should have a %USERPROFILE%\.vim directory with your configuration, and your vimrc file. It won’t do you any good though, because Vim will ignore it. So we need to do what we did on Linux and create some soft links. If you are running Vista or above, you are in luck. The recent versions of windows come equipped with a mklink command (even home editions). So you just do this:

mklink /d vimfiles .vim
mklink _vimrc .vim\.vimrc

If you start Vim now, everything will work better than expected.

For the sake of argument though let’s assume you are some sort of a wierdork, and you use Windows as your primary platform. You have your environment all set up there, and you want to push it over to your MacBook or something. Here is what you do:

  1. Rename _vimrc to .vimrc
  2. Rename vimfiles to .vim
  3. Move .vimrc into .vim
  4. Create soft links for _vimrc and vimfiles
  5. Put .vim under source control

If you want you can copy and paste these commands to make it happen:

rename _vimrc .vimrc
rename vimfiles .vim
move .vimrc .vim
mklink /d vimfiles .vim
mklink _vimrc .vim\.vimrc

On the other end, you just clone the repository into ~ and soft link .vimrc to .vim/.vimrc and you are all set.

If you are extra clever, you should be using Pathogen to manage your vim plugins. If you do, you will be installing them as subdirectories under .vim/bundle. The cool thing about our modern open source ecosystem is that 90% of these plugins are using git and are on github. So instead of duplicating the code all over the place you can set them up as git submodules like I did here.

For example, to add the nifty auto-close plugin you would do this:

cd .vim
git submodule add https://github.com/Townk/vim-autoclose.git bundle/vim-autocose
git submodule init
git submodule update

If you do this, there is a small caveat: by default git does not pull in submodules when you clone a repository. You will end up with bunch of empty directories but no files in them. So you have to remember to do this immediately after you clone:

git submodule init
git submodule update

In fact, you would probably want to periodically run the submodule update command to automatically fetch fresh and patched versions of all your plugins.

Are your vim files under version control? Are they public? Share in the comments! Also, there is a thread in /code where we are sharing our favorite plugins. Go check it out.

This entry was posted in sysadmin notes and tagged . Bookmark the permalink.



11 Responses to Putting your Vim files under version control

  1. karthik INDIA Google Chrome Windows says:

    I have a surprisingly similar/dissimilar setup: A gargantuan .emacs.d folder stored in a subversion repo somewhere. I don’t code or hop across machines often, so it’s really more of a backup for me. I have a link to it in my Dropbox folder as well for added redundancy.

    I think if I ever lost my .emacs I wouldn’t be able to do anything on Emacs; the default settings and keys are abysmal.

    Reply  |  Quote
  2. What about Windows? Windows sucks.

    Indeed.. Indeed…

    Reply  |  Quote
  3. As karthik said, very similarly we Emacs users have ~/.emacs.d/ as a convenient repository root, with init.el replacing ~/.emacs. That’s exactly what I have checked into Git here,

    https://github.com/skeeto/.emacs.d

    One of the first things I do on any new computer is clone that. After manually setting HOME, this also works properly in Windows.

    Reply  |  Quote
  4. karthik INDIA Google Chrome Windows says:

    @ Chris Wellons: You have a *very* interesting website! Subscribed.

    Reply  |  Quote
  5. astine UNITED STATES Mozilla Firefox Windows says:

    I need to someday organize my emacs files. It’s on my todo list, but behind lots of other worthy causes.

    Reply  |  Quote
  6. Luke Maciak UNITED STATES Google Chrome Linux Terminalist says:

    karthik wrote:

    I think if I ever lost my .emacs I wouldn’t be able to do anything on Emacs

    This is actually something I hear quite often. Apparently there no one true Emacs – there are just millions of hyper-customized Emacs environments tailored to people’s specific needs. :) I think Steve Yegge once wrote like a 50 page blog post on this topic.

    @ karthik:

    Yeah, Chris does some very interesting stuff on his blog. I love the embedded video instead of a picture thing. Very subtle but freaky effect.

    @ astine:

    Make sure you at least back them up. :)

    Reply  |  Quote
  7. STop DENMARK Google Chrome Linux Terminalist says:

    I’m slowly getting the hang of vim (your fault!)… I may try this sometime…

    What I don’t really get, is why Moolenaar changed the dot-file thing on other platforms. AFAIK, most other *nix apps that have been ported to mainstream platforms, do fine with dot-files and directories. Furthermore, most Windows-centric editors (like notepad++) handle dot-files with no issues, so why?

    As a footnote: I have been using symlinks for ages to “synchronize” configs and data on dual-boot desktops (usually Linux-Windows). It works fine with Firefox, Thunderbird, Google Earth and Dropbox, among others. Of course, git would bring it to another level…

    Reply  |  Quote
  8. Luke Maciak UNITED STATES Google Chrome Linux Terminalist says:

    @ STop:

    :D

    STop wrote:

    What I don’t really get, is why Moolenaar changed the dot-file thing on other platforms. AFAIK, most other *nix apps that have been ported to mainstream platforms, do fine with dot-files and directories.

    Me neither. I guess the problem is that explorer.exe won’t let you create a file or folder name that starts with a dot. I guess this was the impetus behind the change. But yeah, it makes little to no sense once you realize that as long as you don’t use explorer to create these files/folders (use cmd.exe, cygwin, git bash, your own homegrown code in any language) they will work just fine.

    In fact, if you rename _vimrc to .vimrc on windows, it will still work.

    Reply  |  Quote
  9. STop DENMARK Google Chrome Linux Terminalist says:

    Luke Maciak wrote:

    @ STop:
    In fact, if you rename _vimrc to .vimrc on windows, it will still work.

    Wow! Didn’t know that…

    Reply  |  Quote
  10. Edgar Veiga Google Chrome Mac OS says:

    Nice post :)

    When adding && pulling git submodules you should do it recursively! Try this instead of your solution:

    git submodule update –init –recursive

    Best Regards!

    Reply  |  Quote
  11. Pingback: A list of things you may possibly need, but maybe not (2013 edition) | Terminally Incoherent UNITED STATES WordPress

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>