Vim's runtimepath and directories
The runtimepath (
:help 'runtimepath') is a list of directories searched for
runtime files, such as documentation under
doc, colorschemes under
The runtimepath virtually always includes
~/.vim (for user settings), the
vim runtime (shipped with vim), and
~/.vim/after (for overriding or extending
anything that came before). You will probably also find
similar; this is used (I think) by programs that wish to install some of their
own vim files when they are installed (e.g., I think clisp came with some extra
Plugins, packages, and package managers may manipulate the runtimepath; consult
the relevant documentation for information.
:put =split(&rtp, ',') a handy shortcut to produce a list of my
Vim's user customization (
:help startup and
At step number 3 of the startup process, vim will read a vimrc file. It can be
located in several places, depending on your operating system. Most of them
allow you to use
~/.vim/vimrc, which is relevant for our
discussion. The first one found is used, in the order given.
So to use only
~/.vim/vimrc, it must be the first file in the list of vimrc
You can often check what vimrc was detected with the command
Here's another relevant bit of documentation:
RECOMMENDATION: Put all your Vim configuration stuff in the
$HOME/.vim/ directory (
$HOME/vimfiles/ for MS-Windows). That makes it
easy to copy it to another system.
More details are at
So, I can't and won't give an overview of git here. It's too big. But I'll link
you to some resources:
- a workshop I gave to get people up-and-running with git (and not lie to them
about the underlying model):
- a list of resources I collected for the workshop:
- in particular, the git book
One thing I will say about git's model is that by default, the directory
.git/ is the "top" or "root" of a git-tracked repository. Also by
default, git will not track any file you don't
git add to the repository
first (so new files are initially "untracked"). As far as I know, it is very
difficult (perhaps impossible) to track files that are above the root of the
So, if you have
|- .git/ ...
|- autoload/ ...
It will be very hard (if not impossible) to track
~/.vimrc in the same repo.
Luckily, you can track
Lastly, git has a concept of "ignoring" certain files (like compiled binaries or
tags produced by
:helptags). But you tell it what to ignore using files like
.gitignore and the one named by
core.excludesFile. See both
git help ignore
git help config.
In this situation…
Well, it really depends on what you want to do. As I've tried to explain, both
vim and git give you the power; they don't do much without you asking, but
you've got to learn their core models and their defaults well enough to
understand what to ask them to do.
In this case, I would suggest
~/.vim/vimrc, and don't even try to do
- If you don't want to commit everything in a repository, don't
git add.—that's how you tell git to track everything in a repository.
- If you want to ignore some things in git, learn how gitignore works (see the
reference I gave above).
- If you want git to track a file,
git add file and
git commit are the best
ways to tell git to care about a file for the rest of its life. (Of course,
you still have to
git add and
git commit when you've made changes later,
but now those changes will show up in
git status and
git diff, because
the files are "tracked".)
- If you want to "start over" to try to set things up with git the right way
the first time around, you can remove the
.git directory. But I would make
a backup copy of your entire
~/.vim somewhere, just in case things go
awry. You can also make a second backup without the
.git directory to try
practicing git before you go and setup your
~/.vim directory for real.
(This is much simpler than trying to use
git rebase and
to clean up a mess, particularly when the repo is small, personal, and has a
short history. In a bigger setting, such as a large open-source project or a
corporate project, such a thing would be Very Bad™. You would want to learn
how to use rebase and filter-branch on only your local commits for that
situation. Once commits are pushed/public, it is best to leave them
untouched. You can always create a new branch to try to clean them up.