5

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?

JLDiaz
  • 1,248
  • 9
  • 21

2 Answers2

4

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.

romainl
  • 186,200
  • 21
  • 280
  • 313
  • Ok, but I guess that some more configuration is needed to be able of merging changes in the original repo. If I use 3, I should add the original repo as upstream, in addition to my own forked copy, didn't I? And if I use 4.. how could it be done? – JLDiaz Jul 10 '13 at 16:03
  • My *opinion* is that you shouldn't care about the original repository. If your changes are "private", as you put it, they are, by definition, not meant to be pushed upstream. If ou feel like it it is easy enough with github to make a pull request so, if I was in your shoes I wouldn't think too much about it. Whatever you do to your own fork of fugitive, you don't have commit rights over the original repo anyway so... why bother. It's one thing to be a good github citizen and another thing to waste your time on such hair splitting. – romainl Jul 10 '13 at 19:41
  • Sorry for the confusion. I didn't mean to push my changes, but instead to pull the changes in the original repo and merge them with my own customizations. I think this makes sense in order to be always up-to-date and also keep my customizations. – JLDiaz Jul 11 '13 at 09:10
  • Just keep the original repo as a remote in your own fork, then. You are right that you must do a lot of configuration. I'm not sure all that stuff warrants so much effort: that's only the config files of an editor, not a paid project that puts money on the table so I usually don't care that much. My config is a single git repo, all of my few plugins are either dead or very stable and I don't spend much time "managing" all that and "staying up-to-date". Your anxiety is somewhat understandable (and widely distributed) but unfounded. – romainl Jul 11 '13 at 09:21
1

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.

Richard Fletcher
  • 441
  • 4
  • 2
  • Using git-subtree for Pathogen is explained here: http://endot.org/2011/05/18/git-submodules-vs-subtrees-for-vim-plugins/ – mahemoff Jan 07 '14 at 00:20