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

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

[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?

[jdevera]

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

[jdevera]

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.

[lucc]

The logic looks good to me.

[jalcine]

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.

[jdevera]

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.

[jalcine]

Gotcha; cool!

[lucc]

Maybe there is some usable code in #267.

[jdevera]

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.

[firedev]

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' }

[BatmanAoD]

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

[jwhitley]

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.

[MarcWeber]

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

[mcandre]

+1

[cknoerle]

👍

[stevschmid]

👍

[Peeja]

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

[mcandre]

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

[jalcine]

That was unnecessary @mcandre.

[wolph]

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.

[jdevera]

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.

[interfect]

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.