Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request , bundle-like version lock ? #253

Closed
dfang opened this issue Jan 5, 2013 · 12 comments
Closed

feature request , bundle-like version lock ? #253

dfang opened this issue Jan 5, 2013 · 12 comments

Comments

@dfang
Copy link

dfang commented Jan 5, 2013

locking plugins version is more safe , why ? please see this issue preservim/nerdtree#223

another solution is i fork all the plugins , and in my vimrc , bundle that . but ................

@LevelbossMike
Copy link

👍

locking version or checking out branches would be a great feature.

@greduan
Copy link

greduan commented Jan 5, 2013

So you mean like being able to specify the specific commit at which it should lock on? In other words, make that plugin not update?

@LevelbossMike
Copy link

Exactly. 👍

@greduan
Copy link

greduan commented Jan 6, 2013

I see, that would be a useful thing, I agree this should be a feature.

@bbinet
Copy link

bbinet commented Feb 7, 2013

+1.
This is the only reason why I'm still using git submodules + pathogen to handle my vim plugins.

@ghost
Copy link

ghost commented Feb 15, 2013

Something along the lines of

Bundle 'repository-stuff' 'commit-hash/tag/branch'

For example

Bundle 'gmarik/vundle' '0.9.1'

Which is almost the same as ruby Gemfiles

@deiga
Copy link

deiga commented Feb 15, 2013

I don't know enough vim scripting to be able to implement it, but I can give some specifications for the implementation.

The URL scheme would be:

  • branch => repo/name/tree/<branch name>
  • commit => repo/name/commit/<commit hash>
  • tag => repo/name/tree/<tag name>

@ghost
Copy link

ghost commented Feb 15, 2013

That would be another way to solve it without a second argument yes, and removing the ambiguity of branches/commits/tags

@steveno
Copy link

steveno commented Feb 19, 2013

👍

@hupili
Copy link

hupili commented Jul 15, 2013

👍 what's the status of this issue? Looking forward.

@deiga
Copy link

deiga commented Oct 19, 2013

Can we get a decision about this feature?

@maljub01 maljub01 mentioned this issue Oct 22, 2013
@jdevera
Copy link
Contributor

jdevera commented Oct 31, 2013

Closing as dup of #35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants