Support for locking onto a Tag or Branch about vundle.vim HOT 74 CLOSED

Since this seems to be quite the active issue I'll mention here that I'm no longer working on Vundle.

So if somebody really wants to see this feature, they could perhaps give it a try. The PRs that are currently attempting to implement this feature all fall short in one or another, so maybe it's just a matter of picking from all of them.

All the best.

from vundle.vim.

👍

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

from vundle.vim.

A GitHub etiquette PSA: Please refrain from adding +1s to already-popular issues. It spams everyone interested in the issue and contributes nothing to the discussion. Gauging interest is important at the beginning of a feature discussion, but at this point no amount of +1ing will make this feature happen any faster.

+1

from vundle.vim.

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

from vundle.vim.

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

from vundle.vim.

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!

from vundle.vim.

Right now I'm at Raimondi/delimitMate@9efb01d. 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 :)

from vundle.vim.

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 Shougo/neocomplcache.vim@d04a28b

vim-scripts is currently on 6.0: vim-scripts/neocomplcache@7071d98

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.

from vundle.vim.

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!

from vundle.vim.

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 ...

from vundle.vim.

Thanks @Taverius, will try to fix this

from vundle.vim.

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

from vundle.vim.

+1 for explicit branches

from vundle.vim.

@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.

from vundle.vim.

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

from vundle.vim.

Listens in…

from vundle.vim.

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

from vundle.vim.

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

from vundle.vim.

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

from vundle.vim.

@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

from vundle.vim.

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.

from vundle.vim.

+∞

from vundle.vim.

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

from vundle.vim.

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'

from vundle.vim.

+1

from vundle.vim.

Any update on this issue?

from vundle.vim.

+1

from vundle.vim.

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.

from vundle.vim.

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

from vundle.vim.

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 :)

from vundle.vim.

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

from vundle.vim.

+1

from vundle.vim.

👍 :)

from vundle.vim.

👍

from vundle.vim.

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.

from vundle.vim.

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

from vundle.vim.

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 :/

from vundle.vim.

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.

from vundle.vim.

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.

from vundle.vim.

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

from vundle.vim.

@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

from vundle.vim.

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.

from vundle.vim.

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:
Shougo/neobundle.vim#134

from vundle.vim.

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.

from vundle.vim.

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.

from vundle.vim.

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

from vundle.vim.

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!

from vundle.vim.

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.

from vundle.vim.

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.

from vundle.vim.

+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

from vundle.vim.

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.

from vundle.vim.

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? 😄 )

from vundle.vim.

@lucc: That looks like it'd work for practically every case. I'm curious to know if this would work if it were a git sub-tree or a submodule.

from vundle.vim.

@jalcine not sure what you mean. Do you think people will keep plugins fixed on submodules? How should such a thing work?

If you just want to check if a string is a branch, tag or commit in a submodule I do not know if the above will work. You will have to find out yourself.

from vundle.vim.

I've met a few who have; since they didn't use a plugin manager. It makes sense too if your vim setup is versioned as well.

It'll work but it'd have to be done within the directory of the plug-in. The $GITDIR/.git directory is stored in its parent but it'd be able to refer to it.

from vundle.vim.

I never understood why people want to mix Vundle and submodules, it seems so weird as using two plugin managers at a time. In any case, since it a scenario that is not supported by Vundle, I'm paying zero attention to that case.

I haven't pushed anything yet because I barely have short time here and there, but with the info from that stackoverflow answer I have something like this (not tested at all)

func! s:check_command(dir, command)
  let cmd = 'cd ' . vundle#installer#shellesc(a:dir) . ' && ' . a:command
  let cmd = vundle#installer#shellesc_cd(cmd)
  s:system(cmd)
  return !v:shell_error
endf

func! s:is_branch(bundle)
  let ref = a:bundle.ref()
  let path = a:bundle.path()
  return s:check_command(path, 'git show-ref --quiet --verify "refs/heads/' . ref . '"')
endf

func! s:figure_out_sync_update_command(bundle)
  let ref = a:bundle.ref()
  if s:is_branch(a:bundle)
    let ref = 'origin/' . ref
  elseif s:get_current_sha(a:bundle) == s:get_sha_for(bundle)
    " We are there
    return ''
  endif
  let cmd = 'git fetch origin && git checkout ' . ref
  endif
  return cmd
endf

The idea is that, for a non-branch ref, we check if we are already there, and if we are not, we fetch and check it out. For a branch, we always fetch, since it is a moving target, and then checkout the remote branch (without creating a local tracking branch, for simplicity).

from vundle.vim.

In any case, let's not care about the vim script right now, only the flow of git commands and conditions for each case, that's the thing that needs thinking, the rest just needs doing and we can talk about when I send the PR.

from vundle.vim.

The logic looks good to me.

from vundle.vim.

How far should support for tracking remote branches to their local counterparts go? I found this link on Stackoverflow for pulling the branch that a ref on a branch would track just so you don't have to hard code to origin:

git for-each-ref --format='%(upstream:short)' $(git symbolic-ref -q HEAD)

Not sure how I would update your snippet, @jdevera, to have something like this in there.

from vundle.vim.

My working theory for now is that since we are not doing development on the blundles, just getting the updates, we don't really need local branches to track remote branches. All we need is to have those updates checked out, that why I'm doing git checkout origin/<branch> for branches.

from vundle.vim.

Gotcha; cool!

from vundle.vim.

Maybe there is some usable code in #267.

from vundle.vim.

Thanks @lucc that's an interesting one, I had forgotten about that PR. I'll try to read through it more carefully but initially I saw that is using git commands pipe to grep for some things and I wonder how much of that is supported in Windows with the standard installation methods we provide. Whatever we do should work on windows with the current installation instructions.

from vundle.vim.

Oh please, that would be great, check this for example: AndrewRadev/splitjoin.vim#47 (comment)

I wish I could specify something like this in .vimrc:

Plugin 'AndrewRadev/splitjoin.vim', { branch: 'splitting-ruby-arguments' }

from vundle.vim.

Here's another vote for this feature; the latest version of Python-Mode is currently broken on Windows. (See python-mode/python-mode#422)

from vundle.vim.

The use case that brought me here: I've just fixed a bug in a popular plugin and submitted a PR for a fix. I have no idea if/when my branch will be pulled, but I'd like to use it in the meantime. I could simply merge to my master branch, but I prefer to track upstream unless/until I determine that upstream isn't going to respond for whatever reason. Syntax similar to @firedev's above, or @Xerkus' treeish support, or similar would be very handy.

A related use-case: I'd like to switch to an experimental branch for a plugin, either one I'm developing myself or someone else's I'm helping to test. I could just use a local repo, but I'm often working across multiple systems or VMs while that plugin development proceeds.

from vundle.vim.

VAM's situation is: you can pass revisions along with plugin names, and you could overwrite the update hook to change the branch. However VAM has another way: You can define ~/overrides and define a function which looks in ~/overrides for plugins first, then in ~/.vim/bundle like directory. Thus by either setting or not setting a custom function telling VAM about plugin locations by name you get something similar, even better. Thus it could be done, but nobody has done it yet. In the Vundle case probably there is also a way to change the bundle directory. Changing the directory would allow you to keep unclean repositories on disk and run multiple vim instances with different behaviors which could be useful when coding ..

from vundle.vim.

+1

from vundle.vim.

👍

from vundle.vim.

👍

from vundle.vim.

A GitHub etiquette PSA: Please refrain from adding +1s to already-popular issues. It spams everyone interested in the issue and contributes nothing to the discussion. Gauging interest is important at the beginning of a feature discussion, but at this point no amount of +1ing will make this feature happen any faster.

(Apologies for further spamming the subscribers on this issue. I hope this post results in stopping more email than it generates.)

from vundle.vim.

That was unnecessary @mcandre.

from vundle.vim.

Personally I'd prefer a syntax like this:

Bundle 'gmarik/Vundle.vim@branch'

Where branch could be a tag or specific commit as well :)

I wouldn't mind creating a pull request for this btw, shouldn't be too difficult.

@Peeja: unfortunately it does help somewhat... it attracts more attention, it shouldn't but... it does.

from vundle.vim.

I think this should be re-opened. It looks like the syntax user/repo@version added in #604 doesn't work as of b255382, and the commit 272d9fe from #604 is not in the current history.

from vundle.vim.