For a long time I have accumulated different configurations for vim for the different open source projects I’m contributing or have contributed in the past. It became a giant unmaintained file for ftplugin/ftdetect with regexes to match the dir name and try to apply every important thing a project needs: from coding style to commands to build the source code.

After changing my machine and re-installing several softwares, I’m trying to keep my dotfiles more organized. For vim, after looking at some options available I settled in this one, that I think is very short and elegant:

" Git specific configuration
let git_path = system("git rev-parse --git-dir 2>/dev/null")
let git_vimrc = substitute(git_path, '\n', '', '') . "/vimrc"
if !empty(glob(git_vimrc))
    exec ":source " . git_vimrc
endif

Unfortunately I don’t remember where this came from. But it allows you to have an additional vimrc to be loaded depending on the project you are. Since nowadays 99% of the projects I have are using git, it tries to load the vimrc from the git-dir of that project, which is often .git/vimrc.

I also have a ~/.vim/repo_vimrcs/ in which I keep the configuration files for projects I may have more than one tree or checkout. Inside each of those trees I only need to have a symlink to point to the “one source of truth” for configuring that project:

.git/vimrc -> ~/.vim/repo_vimrcs/linux.vimrc

In this file I can keep the coding style and also configure makeprg to do the right thing when trying to build that project. For example, this is what I have for igt, that uses meson as build system:

let &makeprg='ninja -C build'

git helper for “recursive rebase”

Very often I’m in the middle of an interactive rebase and while editing a commit I remember I should have changed a commit that I initially didn’t mark on the rebase todo. If you tried to git-rebase again you would notice it’s not possible due to git’s bookkeeping of the current rebase.

In the past what I usually did was to either 1) Continue the rebase and then rebase again to fix the previous commit or 2) Create a fixup commit with git commit --fixup and then rebase again with --auto-squash.

Now I have a helper …

Page 1 / 1

Politreco by Lucas De Marchi

Other articles

git helper for “recursive rebase”

Other articles

blogroll

social