All geek questions in one place

Configuring vim packages using pathogens and git submodules

I use vim on different machines and want my configuration to synchronize between them, so I tried to use the well-known pathogen approach to install different vim plugins, saving them as git submodules, as described, for example, here .

Now my .vim folder is a git repository that contains each folder in .vim/bundle as submodules. I uploaded this main repo to a bitbucket and cloned 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 you would like.

Now the problem arises when I need to make some settings in some of these plugins. For example, some of the submodules are just vim colors schemes. Suppose I want to change, say, the color of comments. What would be the right way to do this?

Some ideas came to my mind:

  • If I directly change .vim/bundle/vim-github-colorscheme/colors (for example), then AFAIK, I have to push these changes to the main vim-github-colorscheme repo, which I cannot, and would be funny anyway. My settings are private in nature. But if I do not synchronize with the submodule repository, these changes will not be visible from my other machines.
  • If I save my own colorscheme settings in .vim/colors , then these changes will be part of the main repo, and they will be easily shared between machines, but this violates the “bundle” of pathogen philosophy. In addition, I do not understand how to perform this method of other settings (for example, modifying some fragments for snipMate or even changing the plugin code).
  • Should I make a private plug-in plug-in, upload it to bitbucket and use it as a submodule instead of the original one? Thus, at least I could correctly make the approach in 1., but it does not look like a good option. Specifically, because I don’t know in advance if I will need to configure the plugin, so this will force me to fork every new vim plugin that I install, just in case.
  • I could save the package code in one git repository, i.e. Do not use submodules at all. This will give me the freedom to modify them, synchronize the changes with my bitbucket replica and deploy them to all my machines with a single git pull . However, this way, when changes are made to the original source of the plugin, it will be difficult to combine it with my own modifications.

I have run out of ideas, and all of the above seems to me wrong for one reason or another. How do people who use git and pathogen manage this scenario?

+4
source share
2 answers

3 is the best solution for your use case. You do not need to create all these forks systematically: unlock the plugin only when you really need to change something and replace the original submodule with your fork.

However, I use a mixture of 3 and 4: my plugins are not submodules, and I made two forks for tuning.

+4
source

There is another solution. Using the Git merge, you get a copy of the official repositories of all the plugins, each of which has its own branch. Then in one of your branches they all exist together, and you can edit plugins as much as you want, and when you want to update, you check each branch of the plugins, update it and then merge it back into the branch where everything lives.

Your changes to the plugin will be merged as you expected.

It gives you all the flexibility and solves your problem, but it is a little painful to set up and it is a pain to maintain relevance.

+1
source

Source: https://habr.com/ru/post/1490674/

More articles:


All Articles