I use Vundle as plug-in manager in Vim and it happens that I want to make modifications to some plug-in to correct bugs or to implement personal changes.
What I do in general is
- fork the original repo
- edit the
.vimrc
file and change the linePlugin 'original-repo'
toPlugin 'my-fork'
, run:so %
and then:PluginInstall
- make changes and commit
- push to my fork
- send a PR
At this point the PR can be accepter or rejected. In the former case, everything's ok. What about the latter case?
What I mean is that in general I can decide to keep the unaccepted edit in my fork (I've just committed it, after all), as well as in the local branch (that is, I keep Plugin 'my-fork'
in my .vimrc
file), since I consider this edit to be important to me, for some reason.
On the other hand, I don't want my fork to get old just because I diverged by one or a few commits; that is, I still want to have my fork include new commits of the original repo.
In addition, I want to be still able to send PR of other commits I can do, paying attention to the PR best practice of sending PRs from a synced fork.
I can imagine what the tools are fit for purpose, i.e.
- the web for creating the fork and send PRs
git
to manage different branches of the local forkVundle
to manage Vim plugins
which I'm already using.
So the question is: what is the workflow I should follow to manage Vim plugins to which I can possibly participate with PRs of commits (and I obviously can't know in advance which PRs are accepted and which are rejected)?