Customizing vim bundles using pathogen and git submodules

Question

I use vim in different machines and want to keep my configuration synced among them, so I tried the well known approach of using pathogen to install different vim plugins, keeping them as git submodules as described for example here.

Now my .vim folder is a git repo, which contains as submodules each folder in .vim/bundle. I uploaded that main repo to bitbucket and cloning it from my other machines, and after some git submodule init and git submodule update I get the same configuration in all of them as wanted.

Now the problem comes when I need to make some customization in some of these plugins. For example, some of the submodules are simply vim colorschemes. Assume that I want to change, say the color of the comments. Which would be the proper way to do so?

Some ideas came co my mind:

1. If I modify directly .vim/bundle/vim-github-colorscheme/colors (for example), then AFAIK, I should push those changes to the main vim-github-colorscheme repo, which I cannot, and would be ridiculous anyway. My customizations are by nature private. But if I don't sync with the submodule repo, those changes will not be visible from my other machines.
2. If I keep my own colorscheme customizations in .vim/colors, then these changes will be part of the main repo and they will be easily shared among machines, but this breaks the "bundle" philosophy of pathogen. In addition it is not clear to me how to accomplish this way other kind of customizations (eg, modifiying some snippets for snipMate, or even modifying the code of a plugin)
3. Should I make a private fork of the plugin, upload it to bitbucket, and use it as a submodule instead of the original one? This way at least I could properly do the approach in 1., but it does not looks as a good option. Specially because I don't know in advance if I will need to customize the plugin, so this would force me to make a fork of each new vim plugin I install "just in case".
4. I could keep the code of the bundles under a single git repo, i.e. do not use submodules at all. This will give me freedom to modify them, sync the modifications with my bitbucket repo and deploy them in all my machines with a single git pull. However this way, when a change is made in the original source of the plugin it will be difficult to merge it with my own modifications.

I ran out of ideas, and all of the above seem wrong to me for one or other reason. How the people which uses git and pathogen manages this scenario?

Answer 1

3 is the best solution for your use case. You don't need to create all those forks systematically: fork the plugin only when you really need to change something and replace the original submodule with your fork.

That said, I use a mix of 3 and 4: my plugins are not submodules and I've made forks of two of them for customization purpose.

Answer 2

There is another solution. Using Git's subtree merging, you get a copy of the official repositories of all the plugins each with their own branch. Then in one of your branches they all exist together, and you can edit the plugins as much as you please, and when you want to update, you checkout each plugins branch, update it, and then merge it back into the branch where they all live.

Your changes to the plugin will be merged in the way you would expect.

It gives you all the flexibility, and solves your problem, but it is a bit of a pain to set up and it's a pain to keep up to date.