Init/update submodules in git bundles

[Mange]

Some repositories (for example xolox/vim-easytags) use submodules to work. This small change should make those bundles auto-installable.

[gmarik]

-1 on this, sorry.
Here's my thoughts on this:

1. all dependencies should be installed as Bundles (there's TODO on auto-managing dependencies)
2. the dependency xolox/vim-misc isn't "pathogen compatible" plugin.

I understand the idea of putting code into submodule to make it easier for development, but it's Git way not Vim way of doing things.

So, in my opinion, in order to make xolox/vim-misc - a Vim friendly bundle - it has to be modified, in a way that all files have to be put into autoload/xolox/misc directory.

After that:

Bundle `xolox/vim-misc`
Bundle `xolox/vim-easytags`

Should be enough get plugin and dependencies installed.

Let me know what you think.
Thanks!

[gmarik]

And there's request to accomplish that AFAIR

[Mange]

I'm not sure I would come to the same conclusion, but you make a good point. Since it's your project, your taste/direction should obviously take precedence. :-)

[gmarik]

Well, it's not about my taste...it's about having an unified approach to manage all plugins.

Anyway, thanks for feedback!

[gmarik]

I hope @xolox will make his vim-misc pathogen-compatible as well

[xolox]

I can understand where you're coming from @gmarik, but I won't change my git repositories yet again, I don't even use Pathogen/Vundle/whatever and since I switched to GitHub I've had more work changing the repository layouts to suit those damn programs than I've invested time in actually improving my plug-ins, and frankly, I'm getting sick of it, so there :-P

If I switch to the setup you suggest I'll undoubtedly have lots of GitHub users complaining that the repository isn't complete and a checkout doesn't include dependencies. I've been there before and have been able to make it as easy as git clone --recursive but that's where I draw the line, I'm not going to split these files up yet again.

Edit: Yesterday I read about an alternative to git submodules (which suck anyway) that merges one repository into a subdirectory of another repository which would enable me to update the vim-misc scripts with the least amount of trouble while keeping compatibility with Pathogen/Vundle. I'll investigate this soon.

[Mange]

@xolox: Is it possible to detect if vim-misc is in the rtp already and in that case load from there. This would give us the best of both worlds; if the user is using Pathogen or Vundle, they just have to make sure that vim-misc is loaded first. If not, a normal git clone --recursive would suffice to solve the problem.

Thoughts?

[gmarik]

@xolox, i guess ppl should just send more requests to convince you to...;)
maybe another year or two... ;)

[xolox]

@Mange: It is possible to detect that vim-misc is already installed (in fact I don't have to do anything for this to work, it's inherent in how Vim autoload scripts work) but there's a catch: The vim-misc repository doesn't contain a directory structure because of two limitations of git submodules:

• Submodules can only include complete repositories; you can't include a subdirectory of one repository inside a subdirectory of another repository. To make your suggested setup work, the vim-misc repository would need a directory structure which then makes it impossible to use as a submodule...
• A submodule can only be included in a directory that doesn't contain anything else, i.e. you can't include a submodule in your repository and have it act as an overlay on the repository.

I could create a vim-misc-standalone repository which just defines the directory structure and includes vim-misc as a submodule, but I don't like superfluous repositories just to please programs which I don't use. Anyway, I'm hoping the "merge one repository into a subdirectory of another repository" trick works out, because then git clone --recursive wouldn't be needed and the repositories would be compatible with all of the different Pathogen/Vundle/whatever tools out there.

[xolox]

@Mange: After reading up on the git subtree merge strategy (what I referred to in my earlier messages) I removed the submodule from the vim-easytags repository and merged vim-misc as a subtree instead. This means a regular clone now includes everything needed to get started. If you can confirm that it now works out of the box with Vundle then I'll use this alternative strategy for all of my repositories and everyone will be happy :-)

@gmarik: Sorry for venting my frustration here in my first message, that's not a very nice way to introduce myself. I'm hoping that the git subtree merge strategy will prove to be a good solution for Pathogen and Vundle users (regarding ease of install) and myself (regarding ease of maintenance). I just want to be able to work on my plug-ins instead of managing git repositories all day long :-P

[gmarik]

@xolox, no problem!
Glad you've found a solution that makes everyone happy! )

[othree]

For my case.
I modify jslint.vim to use the latest jslint.js from other repo.
Which is not another VIM plugin, but better to use submodule to get the latest file I need.

[jbking]

For my case.
I'm using the bundle 'kevinw/pyflakes-vim'. It has a dependency to his customized 'kevinw/pyflakes' which is a python component, and it should be setup to appropriate place into pyflakes-vim/ftplugin/python for vim-python. git submodule configuration only has such information.

Of course, I can execute git submodule manually at each time, it works fine. But if I forget/didn't know it, I shall get dependency error.

This is a better case to use with submodule.

[sorin-ionescu]

I second the pyflakes-vim problem. Bundles may have dependencies on Python, Ruby, and native C code. Some come with just submodules. Others come with make and rake files. Vundle should take care of it. It should just work.

[randymorris]

I think once the events branch is updated and working with HEAD it would satisfy most of these cases. Having vundle manage dependencies would start to cross into the way vim-addon-manager works and it just seems like too much of a headache for the maintainer.