Closed andreicristianpetcu closed 10 years ago
The problem is the fact that we do not have rollback for plugin updates.
I'm not sure if you're aware of this but you can selectively rollback previous updates using :PlugDiff
command. I could imagine a workflow like the following:
PlugUpdate
to update pluginsPlugDiff
to see the commits from the previous updateX
key to undo the updates from the broken plugins'frozen': 1
option to the Plug
commands of the broken plugins to avoid updating them in the futureI'd given thought about .lock file scheme once, but decided it's not really worth the effort, considering that I'd never really needed the feature anyway. I ended up adding the following command to my .vimrc just in case.
command! PlugSnapshot !tar -cvzf ~/.vim/plugged.tgz -C ~/.vim plugged
It's much simpler and it just works :) Most of the Vim plugins are small so the archive is not going to take up a lot of space. I know it's a different story if you want to store the commit hashes of the plugins in a source repository. But I am not really sure if we should implement it in vim-plug. (You know I try hard to keep the feature set of vim-plug as small as possible) Alternatively, we can easily write a shell scripts to collect the information, and another for restoring the status using the info.
No vim plugin manager has this feature from what I know.
EDIT: Even vim-flavor do not handle commit hash.
No vim plugin manager has this feature from what I know. There are some plugins that let you do this but manually (vim-plug has this feature from what I know). Do you think it would be difficult to implement? Do you think this would be a cool feature? Thank you for developing this great plugin! :)
neobundle has :NeoBundleRollback
for it.
I have pushed a PoC implementation of PlugSnapshot
command to snapshot
branch that generates a shell script for restoring the snapshot of the plugins. Not sure if I want to keep it or not.
Personally I prefer the
1. PlugUpdate to update plugins
2. Realize that some of the plugins stopped working
3. PlugDiff to see the commits from the previous update
4. X key to undo the updates from the broken plugins
5. Additionally, you can add 'frozen': 1 option to the Plug commands of the broken plugins to avoid updating them in the future
So I can froze just the one or two plugin that cause any trouble and leave the rest alone.
Cool stuff! I tested it and it seems ok :D I'm trying to figure out if I can use somehow relative paths. Maby I can trick it somehow. Thank you for this feature! I would like to see it in master :D
@junegunn for PlugSnapshot
to work, some kind of "unix" is required even on windows, right? or I misunderstood the code?
@vheon Yes, I completely ignored Windows-compliance :smirk: Hashbang, chmod, and vim command should not work correctly on Windows. If we want to merge PlugSnapshot
to master, we should find a way to make it work on Windows as well. (Or simply disable the feature on Windows)
@andreicristianpetcu Yeah, I think we could factor out the prefix of the paths using a bash variable.
I tried with $HOME and it did not work. It took the full path.
Windows is always making stuff harder :( It's such a complicated operating system. OS X at least has a third party package manager (brew). If it were my choice I would disable the feature on non-posix compliat operating systems. It's frustrating that even if I don't use Windows, windows blocks such a cool feature to be merged into master.
@Shougo from what I understand :NeoBundleRollback does not have the fine graned version management I need. I want to have unstable stuff on my home computer Arch GNU/Linux and always stable on my work computer Ubuntu. With Plug's snapshot feature I can save all my stable stuff to a branch that I can use at work, and a development branch for my dev machine.
I don't want just a rollback, I want a shared rolleback that I can commit and checkout in my dotfiles.
OK. I get it.
Merged to master with some improvements (with preliminary support for Windows) Note that I removed the alignment of the command arguments and sorted the list so that it's more suitable for version control.
Known issues:
I tested it and it seems ok. How can I change $PLUG_HOME? Can I set it in my vimrc?
@andreicristianpetcu $PLUG_HOME is g:plug_home which is where the plugins are installed which can be configured as the argument of plug#begin('my/cool/path')
or setting the g:plug_home
variable (which btw @junegunn that is not documented in the README) or by default vim-plug will use, and create if necessary, the plugged
directory in the first directory of &runtimepath
so usually is ~/.vim/plugged
.
@andreicristianpetcu @vheon
FYI, vim-plug sets up a couple of g:
variables, but they're designed to be read-only.
See https://github.com/junegunn/vim-plug/wiki/api#global-variables
I want my vimrc to be user independent so that I can use it at work and at home. I set the g:plug_home variable to $HOME/.vim/plugged but the snapshot does not save any git reset lines in the file.
It shows this PLUG_HOME=$HOME/.vim/plugged instead of this PLUG_HOME=/home/andrei/.vim/plugged which is great. But all the git reset lines are no more. Check this commit: https://github.com/andreicristianpetcu/dotfiles/commit/8c612ca4bf8c85dafae9e611a281ab001d928a5c
You should not manually set g:plug_home
. It is determined by plug#begin(path)
call and is not supposed to be overridden. Currently PlugSnapshot
will generate script with absolute paths, so what you can do is to edit the PLUG_HOME line from the generated script yourself, but I'll see if there's a better option.
I can change it with "sed" or something. I just wanted not to do a hack if there is a elegant way to do it.
@andreicristianpetcu Check out the latest commit. I updated PlugSnapshot
to use the exact path argument given to plug#begin()
instead of the absolute path.
Can vim-plug make snapshots of the plugins? Think of Bundler for vim plugins. I want my plugin manager to save in a file (like Gemfile.lock for ruby let's say vim-plug.lock) all the sha1 codes of the commits for each plugin. If I update some plugins, the file with the snapshots changes. I figure out that this update broke something. Until it's fixed I can checkout the last revision with the previous updates so I revert vim-plug.lock to the previous version.
The problem is the fact that we do not have rollback for plugin updates. I manage 70+ plugins in my vimrc. If I update my plugins and one of them totally breaks my vim I have no option but to remove the broken plugin or try to figure out what commit broke the functionality. Sometimes it is difficult to figure out what plugin created the problem.
No vim plugin manager has this feature from what I know. There are some plugins that let you do this but manually (vim-plug has this feature from what I know). Do you think it would be difficult to implement? Do you think this would be a cool feature? Thank you for developing this great plugin! :)