Vim-plug: How to update a modified plugin?

[SolaWing]

Suppose I have a plugin and add some custom modification. I wish to keep to update with original like git pull does, and only notify me when some conflict occur. How can I achieve this?

---

• Type:
  
  
  
  • [ ] Bug
  
  
  • [ ] Enhancement
  
  
  • [ ] Feature Request
  
  
  • [x] Question
  
  
• OS:
  
  
  
  • [ ] All/Other
  
  
  • [ ] Linux
  
  
  • [ ] OS X
  
  
  • [ ] Windows
  
  
• Vim:
  
  
  
  • [ ] Terminal Vim
  
  
  • [ ] GVim
  
  
  • [ ] Neovim
  
  

[junegunn]

:PlugUpdate does exactly that. Merge will succeed if there's no conflict, but otherwise it'll fail and vim-plug will let you know of the error (the error message can be improved though).

[junegunn]

[SolaWing]

while I do :PlugUpdate, it notify me
fatal: Not possible to fast-forward, aborting.
If I do git pull on the repository directly, it's fine.

[junegunn]

It means you have local commits. Uncommitted changes without conflicts are fine, but if there's a local commit, vim-plug will refuse to merge as it will inevitably lead to confusion.

[SolaWing]

what confusions it can make? I think saving modifications in commit is a good behavior. this is what git used for.

I searched and found https://github.com/junegunn/vim-plug/pull/143 introduced this change. to fix #139, fetch, checkout, merge should sufficient. why need the ff-only option?

If this behavior is designed, can we provide a option to this case?

[junegunn]

I believe the job of a plugin manager is to ensure that the user has the exact copy of the plugin. Once we allow merges, this is no longer true. We can't confidently tell if some issue is due to our local changes or to the changes in the remote. The commit history is altered locally and the commit hashes you see in :PlugDiff window will not be in sync with the original repository. Such discordance can be confusing both for the user and the plugin author when discussing the issues.

Adding an option to remove --no-ff should be trivial implementation-wise, nevertheless I don't think vim-plug should have it as the mere presence of the option can inadvertently lead the users to the path of making local commits when there are better, less confusing ways to customize plugins (e.g. options, autocmds, pull requests, ...).

[SolaWing]

I see. options and autocmds has it's own limitation. pull requests is great, but there are some cases that the modification is personal or for some reason upstream refuse to merge. And I think if the local modification cause issues, it's the user's responsibility.

I will try to remove this limitation in my fork. Thanks for your help.

[junegunn]

Thanks for understanding. Having local commits effectively means that you're managing your own fork of the plugin and I agree that there are times when forking is the only option. It's just that keeping a fork up to date to its origin is beyond the scope of vim-plug.

[097115]

And still, adding something like :PlugUpdate!, a command, which would overwrite a locally changed plugin with its latest version from the repo, doesn't look to me like radically changing the ideology of a plugin manager… What do you think?

[RatanRSur]

Didn't read this conversation in any depth so apologies if this was already covered but could vim-plug not not use git pull --rebase?

[junegunn]

@097115 We already use bang-variants for a different purpose.

https://github.com/junegunn/vim-plug#pluginstall-and-plugupdate

Anyway, how often does this happen to you? And how hard is it to resolve such cases? YMMV, but in my experience (I use a lot of plugins), I rarely run into the case, and even when it happens it takes just a few seconds for me to manually git checkout -f on that repo. More importantly, blindly discarding local changes is almost always not what I want. Given the experience, I don't see much value in the suggested feature. And it's an unsafe operation that makes irrevocable changes. Users may shoot themselves in the foot.

vim-plug exposes its data structure via g:plugs variable. So you can easily implement a function/command that runs git checkout -f (or git reset --hard origin/master) on the plugins.

call map(values(g:plugs), {_, spec -> system(printf('cd %s && git checkout -f', spec.dir))})

You can even define a mapping inside the plug window like the examples shown in the wiki page.

Having said that, if you keep running into this situation. I think you are better off using your fork, or managing the plugin manually ("unmanaged plugins").

@RatanRSur I'd say it's beyond the scope of vim-plug. vim-plug will not do anything more than provide the right revision of a plugin. See my previous comments.

[097115]

More importantly, blindly discarding local changes is almost always not what I want.

Well, my scenario is very simple: I have a few patches specified via {'do': …} mechanism. Thus, I'm not interested in saving local changes at all. Since those would be reapplied automatically every given time.

Also, because of that my usage of do, the map call you suggest won't solve the problem - since it won't run the post-update hook, if I'm right.

I think you are better off using your fork, or managing the plugin manually ("unmanaged plugins").

Well, I do not want to manage those :). All I want is to keep in line with the original changes - and to apply my little patches after updates, that's all.

[junegunn]

since it won't run the post-update hook

You can make it run unconditionally using the bang version of the command. So what you can do is:

1. git checkout -f on that repo
2. PlugUpdate! NAME_OF_THE_PLUGIN

or

1. git checkout -f on that repo
2. PlugUpdate
3. PlugInstall! NAME_OF_THE_PLUGIN

It's a bit of a hassle, right, but you can easily define a helper command that does the above steps.

By the way, why don't you just send a pull request, or ask the author of the plugin to make the plugin configurable?

[097115]

git checkout -f on that repo

You mean actually visiting that ~/.vim/plugged/NAME_OF_THE_PLUGIN folder and running git checkout -f from there? Well, in that case I can just manually delete that folder, and then simply run PlugInstall.. :)

The purpose of my initial comment was a thought that it's somehow possible not to leave Vim for that routine :). Anyway, thanks for your time and for your comments.

BTW, that "Automatically install missing plugins on startup" snippet from the extras page, does it work for you? For me, if there's a missing plugin (i.e., a plugin is mentioned in .vimrc's vim-plug section but its folder is missing), Vim just quits after startup for some reason...

[junegunn]

not to leave Vim for that routine

Well, you don't have to. I showed that you can do it inside Vim using the information stored in g:plugs variable. With a little bit of Vimscript, you have something like MyPlugUpdate that handles everything and you don't have to care anymore.

I can just manually delete that folder, and then simply run PlugInstall

The difference between that and the above procedure is that you don't have to download the entire plugin again.

Vim just quits after startup for some reason

Do you have the latest version of vim-plug? Does :PlugUpdate --sync work synchronously?

[097115]

Do you have the latest version of vim-plug?

Oh, my bad, sorry! Everything works like it should :).

With a little bit of Vimscript, you have something like MyPlugUpdate that handles everything and you don't have to care anymore.

Thanks, I'll have a look into it (unfortunately, my Vimscript is far from good :)).

[junegunn]

Here you go, something like this.

function! DiscardingPlugUpdate()
  let dirties = filter(copy(g:plugs),
    \ {_, v -> len(system(printf("cd %s && git diff --no-ext-diff --name-only", shellescape(v.dir))))})
  if len(dirties)
    call map(values(dirties),
      \ {_, v -> system(printf("cd %s && git checkout -f", shellescape(v.dir)))})
    PlugUpdate --sync
    execute 'PlugInstall!' join(keys(dirties))
  else
    PlugUpdate
  endif
endfunction
command! DPU call DiscardingPlugUpdate()

Honestly, I can't help but admit that this workaround is not elegant. But I'm still not convinced about adding the behavior to vim-plug for the reasons I previously mentioned, and also because I realized there are two separate concerns intertwined here.

1. Discarding local changes
2. Triggering post-update hook even when the plugin is not updated

In your case, you want both, because the local changes are the direct result of the post-update hook. But we can't be sure that is always the case, different use cases and requirements. It's more complicated than I'd like it to be.

[097115]

Thank you very much! (Also, after this explanation, I tend to agree with your reasoning for not adding this functionality to vim-plug.)

[eromoe]

I met this problem, but I didn't do any change to any plugin . Is there any way to force update ?

[hasufell]

I believe the job of a plugin manager is to ensure that the user has the exact copy of the plugin.

I disagree. A plugin-manager is there to aid the configuration of the user, specifically the plugin configuration. If local patches are part of the plugin configuration, then so be it.

Whether to include that feature or not is just personal preference. Neither opinion is correct or wrong, but there is no technical limitation to this, nor a fundamental contradiction to the design philosophy.

The feature can be well-defined and totally optional. That is not the problem. Vim configuration is there to suit my needs and to hack and modify everything I see fit.

[jesseleite]

I met this problem, but I didn't do any change to any plugin . Is there any way to force update ?

Same here, I haven't touched any of these plugins and am getting 'overwritten by merge' warnings :( I end up having to delete my plugged folder and re-PlugInstall. It's happened a few times now when trying to PlugUpdate.

[junegunn]

I haven't touched any of these plugins and am getting 'overwritten by merge' warnings

It's probably because the author of the plugin made a mistake e.g. force-push to a public branch. And that should not (or never) happen in general.

[hasufell]

And that should not (_or never_) happen in general.

That's an assumption. If you are using a development branch of a plugin that might very well happen. That's what git reset --hard is for.

[jesseleite]

It's probably because the author of the plugin made a mistake e.g. force-push to a public branch. And that should not (or never) happen in general.

@junegunn in all respect, but it happens to like 10+ plugins at once, including fzf.vim. You think they were all force pushed? I'll have to screenshot next time it happens.

[junegunn]

@jesseleite I don't think so. Not sure what happened there. For all the years, I've had the problem with maybe a couple of plugins.

@hasufell Yes, and I believe it's a valid assumption for most users. The problem rarely affects me, so I'm not motivated enough to consider adding an option. I've noticed there are alternative Vim plugin managers these days, you might want to check them out.

[hasufell]

Yes, and I believe it's a valid assumption for most users.

Apparently not, if you look at this issue :)

The way this plugin updates repositories is apparently not very robust.

The problem rarely affects me, so I'm not motivated enough to consider adding an option.

That doesn't tell us anything about whether you would accept a PR.

[junegunn]

Apparently not, if you look at this issue

Well, you might want to compare the number of vim-plug users and the number of users who commented here.

That doesn't tell us anything about whether you would accept a PR.

I think I made myself pretty clear here and provided a workaround. You can make a pull request, and use the fork even if I don't accept it.

[hasufell]

Well, you might want to compare the number of vim-plug users and the number of users who commented here.

That's not really how it works. You would have to compare the number of e.g. subscribed people to this issue (or come up with a better heuristic) and I don't think you can :)

I think I made myself pretty clear here and provided a workaround. You can make a pull request, and use the fork even if I don't accept it.

Yes, I assume this is a no.

[junegunn]

Okay, that makes me wonder how you came up with the bold conclusion "Apparently not" :)

[jesseleite]

@junegunn please don't take my comments as negative; I love what you do and all your contributions to Vim! Anyway, it's happening again here, and with one of your plugins (vader.vim) as well. Here's a screenshot...

[hasufell]

I'm not surprised anymore that you require users to come up with statistics before you understand there is some part of the community that would like to have this use case supported :)

On November 20, 2018 6:41:10 AM UTC, Junegunn Choi [e-mail] wrote:

Okay, that makes me wonder how you came up with the bold conclusion
"Apparently not" :)

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/junegunn/vim-plug/issues/510#issuecomment-440161761

[junegunn]

@jesseleite Jesse, it looks like you're having a different problem than the one I described (force-updated remote). The message is saying that you have local uncommitted changes. Have you tried examining git status or git diff output in one of those directories?

[jesseleite]

@junegunn Here's a git status, and a git diff on my ~/.vim/plugged/vader.vim directory.

Interestingly, the diff shows it's related to git tracking unix permissions? In the past I've had permissions errors before when running :PlugUpdate. I believe in the past I have ran chmod -R on ~/.vim/plugged, which fixed that problem, but may have introduced this new problem?

[junegunn]

@jesseleite You should review your global .gitconfig and see if there's an option that might affect file permissions.

[jesseleite]

@junegunn Hmm, not sure I see anything here that would affect it?

[junegunn]

@jesseleite Nothing looks suspicious.

I believe in the past I have ran chmod -R on ~/.vim/plugged, which fixed that problem, but may have introduced this new problem?

Probably. I suggest that you just rm -rf ~/.vim/plugged, reinstall everything, and see if the problem persists.

[jesseleite]

Done. If I get any related permissions or merge errors after doing this, I'll post my findings. Really appreciate your time @junegunn.

[123subhadeep]

Really long discussion and I wasn't able to find the final answer , can anyone tell me what's the TLDR here.

So basically how can I make vim-plug do a "git pull --rebase" on modified plugins instead of just failing ? Thanks.