Support for locking onto a Tag or Branch

[jherdman]

Lately I'm getting burned by installing Vim plugins at HEAD instead of a stable branch or tag version. It'd be nice to be able to lock onto a stable tag or branch to prevent this from happening. Is this a possibility?

[gmarik]

Hey! Can you name few so I can test it? It's on TODO. And you're first to officially complain about it... )

[jherdman]

delimitMate is chief among them right now. Sometimes Command-T gives me grief -- especially because it has bits that need to be compiled.

[gmarik]

Ok, and do you have actual revisions that are causing problems? And could you please provide a little bit more details on how can I reproduce issues?

That's not too relevant to the revision feature, but I just like collecting issues before implementing actual feature...) Thanks!

[jherdman]

Right now I'm at https://github.com/Raimondi/delimitMate/commit/9efb01da683721927589e7e340e8f2374d7dd3ea. It seems to be causing me severe grief, but I'm not entirely convinced the problem is unrelated to delimitMate... I think my Vim install might be generally borked. That said, the described feature would still be the hotness :)

[Taverius]

I've moved from the live tree of neocomplcache to the vim-scripts tree because of this.

Live: incredible slowness on most edit actions (PHP) V-S: works great

I believe the last commit I was on was this https://github.com/Shougo/neocomplcache/commit/d04a28bf432476b07944df481fe890010ec394a6

vim-scripts is currently on 6.0: https://github.com/vim-scripts/neocomplcache/commit/7071d987e20b97ee8822f71b56226cd694566e28

I've also gotten burned like by LustyExplorer, easytags, tmru (out of all things).

I'd really love it for vim-ruby, since it has no vim.org script page and therefore no stable vim-scripts tree.

[gmarik]

pushed v branch which lets specify revision, ie:

Bundle 'Shougo/neocomplcache d04a28bf' or Bundle 'Shougo/neocomplcache', {'v': 'd04a28bf'}

Before testing make sure to checkout the branch:

$ cd vundle && git pull && git checkout -b v origin/v

If you could find some time to test it would be awesome!

[Taverius]

With the v branch, I'm getting:

Error detected while processing function vundle#installer#install..<SNR>65_install..<SNR>65_sync:
line 26:
E344: Can't find directory "`=a:bundle.path()`" in cdpath
E472: Command failed

This is regardless of whether I use the new revision notation, or just do a simple BundleInstall 'neocomplcache' to get the vim-scripts version.

Might this be because of my initial vundle call, call vundle#rc('$HOME/vimfiles/bundle/'), for the windows vimfile path thing?

Either way, bork bork bork! Works on master! :D

Edit: note that the error occurs after the git clone. It does, in fact, successfully checkout HEAD. But it fails to switch revision when asked to do so - no idea why its erroring out when I'm not asking for a revision ...

[gmarik]

Thanks @Taverius, will try to fix this

[chrischambers]

Definitely +1 - this is the only reason I've not tried out Vundle yet!

[aerosol]

+1 for explicit branches

[jfelchner]

@gmarik What's the status on getting this into master? I just got bit by it as well. hammer.vim's master branch is fubar'ed and it'd be really nice to be able to specify a prior SHA/tag.

Thanks for all the work on this BTW. Love it.

[gmarik]

@jfelchner last thing i worked on was this feature, it's in testing stage

[Peeja]

Listens in…

[Peeja]

Any chance there's a way I can help with this? Getting this working would solve a lot of headaches for my team.

[aerosol]

@Peeja in the meantime: https://github.com/kana/vim-flavor

[EvanDotPro]

+1 for this. This is the exact reason I'm still using submodules in my Vim config instead of vundle.

[Xerkus]

@gmarik i've done some refactoring and added git tree-ish support. Branch, tag or commit can be specified now. Also i added functionality to install bundles under different names and 'local' flag to prevent vundle from managing bundle installs and updates, but still registering it's resources. Docs and tests are not updated, check README for changes in Bundle format (BC safe)

I would appreciate comments as this was my first dive into vim scripts and i might have missed something: https://github.com/Xerkus/vundle/tree/feature/refactor-git-treeish-support

[EvanDotPro]

I'll just add that I am successfully using @Xerkus' feature/refactor-git-treeish-support branch without any problems so far (I can't say the same for the v branch). I am very happy to see this added and would love to see this make it into upstream vundle, pending any feedback from @gmarik. Thanks @Xerkus!

Edit: The "local" install functionality is quite handy for Vim plugin developers as well.

[padde]

+∞

[gko]

Is this feature implemented? If so, how to use it?

[svermeulen]

For anyone interested, I needed this feature so I made a small change to allow this on my fork here: https://github.com/svermeulen/vundle.git

Specify using full colon eg: Bundle 'repositoryName:branchName'

[dathinaios]

+1

[frewsxcv]

Any update on this issue?

[afutseng]

+1

[Peeja]

Hey, folks. This is clearly a popular request. Please know that when you leave a "+1" comment, that comment sends a notification to everyone watching this issue, which is a lot of people (because, you know, it's a popular request). It also doesn't speed the process along in any way.

If you'd like to stay abreast of any updates on this issue, please click the "Watch" button at the bottom of the page.

[frewsxcv]

Can we jump start this issue and this pull request? It looks like there's a difference of opinion on the syntax changes

[jdevera]

I'll take a look at this. I think I might cherry pick from the PR and use a syntax that will accomodate further changes without breaking anyone's vimrc.

Is any of the participants in this discussion using Windows? It'd be nice to get this tested in Windows at some point :)

[frewsxcv]

@jdevera I have access to a Windows machine I can test on

[corpix]

+1

[robinkaranu]

:+1: :)

[realmyst]

:+1:

[Shougo]

Yes, this feature is useful. But this is big feature. It may break stablity in Vundle. I think it should be implemented on other plugin management system.

[jherdman]

Why not simply break compatibility in a new major release of Vundle?

[jalcine]

Well, Vundle isn't really versioned anymore. The last time it was two years ago at 0.9.1. This could be part of a 1.0 release; but that'd require a consensus from maintainers :/

[Peeja]

I might suggest that support for specifying Vim plugins by version is not an appropriate feature for a Vim plugin manager which does not have versions.

[Shougo]

This is useful feature, but it is not essential. Yes, it can be implement like NeoBundle. But to decide feature specification is not easy.

but that'd require a consensus from maintainers :/

Yes. It is too hard.

[frewsxcv]

I'm fairly certain @Shougo doesn't want it implemented in Vundle because that would decrease popularity for his project NeoBundle :stuck_out_tongue:

[gmarik]

@Peeja I do expect things to "just work". And be backward compatible. Atleast in Vim plugin ecosystem. I do judge from my own experience. I've used Vim without need to lock a plugin to version so far. And think this 'feature' is far more superior than versioning and i'd rather have a world when things just work rather than wasting time managing versions and compatibilities.

But maybe it's just me, and i'm too naive…

And i see no point other than "best practice" for tagging releases especially when those releases are bugfixes and there's no schedules and plans but just bunch of volunteers contributing casually.

But I'm sure next big feature release will have a properly tagged version. /endrant

[wting]

:+1:

My hacky workaround is to fork vim plugins onto my own Github account and use those within Vundle.

[Peeja]

FWIW, the times I've really wanted this feature weren't to stick with old versions which aren't broken, nor to resolve dependencies, but to have the same version of a plugin on every machine using the same Vim config. When I used to do hardcore pairing and pair rotation, we had workstations with identical setups. In the morning, you'd grab a pair, grab a machine, and start working on a story. It was really annoying that the version of your Vim plugins depended on the time when they were last updated on the machine you were sitting at.

[Shougo]

I'm fairly certain @Shougo doesn't want it implemented in Vundle because that would decrease popularity for his project NeoBundle

Yes, I'm author of neobundle, it may be not fair. I implemented this feature in neobundle, but I hardly use this feature expecting try new branch. And I have seen many .vimrc using neobundle, I don't know people who use this feature.

This is related issue in neobundle: https://github.com/Shougo/neobundle.vim/issues/134

[Shougo]

FWIW, the times I've really wanted this feature weren't to stick with old versions which aren't broken, nor to resolve dependencies, but to have the same version of a plugin on every machine using the same Vim config. When I used to do hardcore pairing and pair rotation, we had workstations with identical setups. In the morning, you'd grab a pair, grab a machine, and start working on a story. It was really annoying that the version of your Vim plugins depended on the time when they were last updated on the machine you were sitting at.

Hmmm... It is like cask management system. Yes, to install same plugin with same revisions in several machines, this feature is useful. But you must search every plugin commit number and write lock revision configurations. It is too hard if you have install 50+ plugins.

[jalcine]

Well, it doesn't have to be only revisions; you could use named refs like HEAD, develop or SHA1s directly. Some plugins have a master and develop branch; it'd be sensible to fix onto those branches.

I, for one, would love to see dependency management support in Vundle, to quasi-quote Ken Jennings.

[MarcWeber]

292 is related, we should move discussion to that issue.

[jdevera]

Hello again everyone, just wanted to give you all a heads up that I'm now thinking on how to implement this. I closed the PR mentioned above explaining why the git commands there would not work.

I'm trying to come up with a set of commands that will work for all kinds of updates.

If we assume we are getting a tag/branch/commit (I'll call it ref) to lock a plugin to, then I'm thinking that for the first installation it's all easy:

git clone <URL> && got checkout <REF>

For updates, however, it seems like tags and commits are in one bag and branches on another, since the former cannot change and the latter can. Ideally for tags and commits, if we are already on that particular version, we shouldn't even have to do any git operation on the bundle. For branches, we'd always have to continue merging from origin. I'm thinking and thinking in a way that I can generalise it to have the same set of commands that will work in both cases but I'm having a hard time with it, so any ideas are welcome. Let's discuss this, this feature is happening!

[lucc]

We can force the user to specify what kind of ref it is by allowing at most one of tag, branch, or commit as options for a Plugin. Then it might be easier.

I do not really like the idea though. I would prefer if it was possible to specify any kind of ref with lets say the ref option.

That said git branch|grep '^\* (detached' is true if we did checkout a tag or lose commit. I only did a short test but it even works if the tag is at the same commit as a branch. One (theoretical) problem with this is that you could name a branch (detached whatever and that would match (unlikely :).

This is not really what @jdevera is aiming at

Ideally for tags and commits, if we are already on that particular version, we shouldn't even have to do any git operation on the bundle.

but I think it comes close.

At the moment I think parsing git branch is a reasonable option.

[jdevera]

I'd rather use only git plumbing commands that are relatively old rather than porcelain commands.

I found a question on stackoverflow, which I though could be of interest for this case.

[lucc]

+1 for plumbing commands.

I just thought of a scenario which looks like a relatively normal use case but gives me a headache on how to handle it: Add a Plugin something to your vimrc, do PluginUpdate and be happy for a while. Add a rev spec to that line at any later time (the only important thing is that the plugin is already cloned).

Problems:

1. the user might expect Vundle to check out the ref for him, otherwise the state on disk or the state of a newly started Vim will not match what is declared in the vimrc
2. if we check out these revs every time Vim is started, we are possibly slowing down startup
3. if we check them out with PluginInstall and friends the user has to do an extra step and until then the old setting (not matching vimrc) will stick no matter what the user does
4. do we start recording the rev option in an external file? That will force us to add some prima facie unrelated feature/code the feature discussed here

[jdevera]

Any changes in the locked ref will only take effect after a PluginUpdate, otherwise, as you said, we slow down startup time to an unacceptable degree. The inconsistency between disk and vimrc is the same as if a user adds or removes a Plugin line or if they change the name attribute.

AFAIK, there is no need to keep anything in external files.

This should be much simpler.

[lucc]

The stack overflow link you gave is interesting. I made this with the idea given there:

func! RefType(ref)
  " taken from http://stackoverflow.com/questions/18222634
  call system('git show-ref -q --verify refs/heads/'.a:ref)
  if v:shell_error == 0
    return 'branch'
  endif
  call system('git show-ref -q --verify refs/tags/'.a:ref)
  if v:shell_error == 0
    return 'tag'
  endif
  call system('git rev-parse --verify '.a:ref.'"^{commit}"')
  if v:shell_error == 0
    return 'commit'
  else
    return 'error'
  endif
endf

Maybe you can use it for your branch (where is the branch by the way? :smile: )