submodule

[ag4ve]

if bundle directory is inside of a git repo, bundles should be added as submodules and not cloned.

[jdevera]

A matter of opinion, I guess, since I, for one, disagree. My bundle directory is in a git repo and I wouldn't like bundles to be added as submodules because that would mean I'd be tracking the bundles for no good reason. Not only I think this is making vundle too clever, but what's wrong with tracking your vimrc on your repo, adding the bundles directory to gitignore and then simply running BundleInstall?

[ag4ve]

my vim directory is in a repo, so when vundle installs a bundle, if the
bundle was a git repo, the whole repo is inside my repo. the alternative
(what i was doing) is making symlinks to the bundle and keeping those repos
outside of my repo, and git doesn't follow symlinks by default. however i
didn't think that was the right way of doing things.

On Wed, Oct 17, 2012 at 12:19 PM, Jacobo de Vera
notifications@github.comwrote:

A matter of opinion, I guess, since I, for one, disagree. My bundle
directory is in a git repo and I wouldn't like bundles to be added as
submodules because that would mean I'd be tracking the bundles for no good
reason. Not only I think this is making vundle too clever, but what's wrong
with tracking your vimrc on your repo, adding the bundles directory to
gitignore and then simply running BundleInstall?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/226#issuecomment-9525137.

[jdevera]

There is nothing wrong with what you are describing, and you don't need to add those repos as submodules. The easiest thing to do is to make git ignore the bundle directory in your outer repo, at least that's what I'm doing.

[ag4ve]

I see we're of a different mindset on how this should be handled. Thanks
for the reply and you can close this.
On Oct 17, 2012 10:27 AM, "Jacobo de Vera" notifications@github.com wrote:

There is nothing wrong with what you are describing, and you don't need to
add those repos as submodules. The easiest thing to do is to make git
ignore the bundle directory in your outer repo, at least that's what I'm
doing https://github.com/jdevera/dotfiles/blob/master/.gitignore#L2.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/226#issuecomment-9529154.

[jdevera]

It was always a suggestion that didn't involve changing the tool. If you still think the tool should change, by all means keep the issue open. I can't really close this, I'm just another user :)

[ag4ve]

oh, i was mobile so didn't realize :)

either way, i don't think most people keep their vim dir in a git repo so
wouldn't notice and i was just asking for the option. as it is, i have to
remove the repo and add the sub module, however if you don't like
submodules, you have to remove the repo from the submodules file, remove
the directory and then go. and you have to know to init your submodules if
you pull the repo somewhere else or have pre subrepo branches etc.

... so, i wouldn't say it should be a default. but, i think using
submodules is the way you're supposed to do this (gives more control if
nothing else) and not symlinks.

On Wed, Oct 17, 2012 at 2:45 PM, Jacobo de Vera notifications@github.comwrote:

It was always a suggestion that didn't involve changing the tool. If you
still think the tool should change, by all means keep the issue open. I
can't really close this, I'm just another user :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/226#issuecomment-9529912.

[weynhamz]

Another reason why submodule should not be introduced is that submodule is mainly for tight integration, it is only useful that parent project is strongly sensitive to the sub project's commit revision. In this case, commit revisions of the plugins is irrelevant to the vim configuration, there is really not necesssary to commit plugins commit infor into vim configuration, so, it is probably not a good idea to use submodule managing the plugins, jdevera's way is much better.

[korjavin]

Yes, i agree.
My .vim is a .git repo. and git clone into bundle/* take me problems.

After that i cant "git clone" my .vim, problem with No submodule mapping found in .gitmodules for path 'bundle/Align'

[ghost]

That sounds more like you accidentally added bundles or something than an issue caused by Vundle itself. My .vim and .vimrc are tracked with GIT and I get no such errors.

[korjavin]

@xeross Just try do git clone. And then ls bundle/*

[ghost]

Okay, show me the commands you execute that cause the problem then

[korjavin]

#backup
mv .vim vim.bak
mv .vimrc .vimrc.bak
mkdir -p .vim/bundle
git clone git://github.com/gmarik/vundle.git .vim/bundle/vundle
echo filetype off >> .vimrc
echo 'set rtp+=~/.vim/bundle/vundle/' >> .vimrc
echo ' call vundle#rc()' >> .vimrc
echo "Bundle 'gmarik/vundle'" >> .vimrc
echo "Bundle 'file-line'" >> .vimrc
echo filetype plugin indent on >> .vimrc
vim +BundleInstall +qall
git init
git add .
git commit -a -m 1
mkdir -p ~/tmp
cd ~/tmp
git clone ../.vim ./vim
ls bundle/file-line
#opps!
git submodule init
#No submodule mapping found in .gitmodules for path 'bundle/file-line'-
#opps!

[ghost]

git submodule init
#No submodule mapping found in .gitmodules for path 'bundle/file-line'-

Why are you doing a submodule init? Alternatively if you didn't mean to add the bundles to your repository:

Alternative

git add .

This also adds your bundles to your repository, registering them as a submodule but without the mapping to a remote repository.

You need to add it to your .gitignore file so you don't add them when using that command:

## Backup
mv .vim vim.bak
mv .vimrc .vimrc.bak

## Create bundle folder
mkdir -p .vim/bundle

## Clone Vundle
git clone git://github.com/gmarik/vundle.git .vim/bundle/vundle

## Configure vimrc
echo filetype off >> .vimrc
echo 'set rtp+=~/.vim/bundle/vundle/' >> .vimrc
echo ' call vundle#rc()' >> .vimrc
echo "Bundle 'gmarik/vundle'" >> .vimrc
echo "Bundle 'file-line'" >> .vimrc
echo filetype plugin indent on >> .vimrc

## Install bundles
vim +BundleInstall +qall

## Initialize git repository
git init

## Add bundles to .gitignore
echo ".vim/bundle/" >> .gitignore

## Add all files
git add .
git commit -a -m 1

## Clone test repo
mkdir -p ~/tmp
cd ~/tmp
git clone ../.vim ./vim
ls bundle/file-line

[korjavin]

Why are you doing a submodule init?

Oh, yes. I doesnt say this. I deploy my .vim to all my servers with puppet, and perfect module 'vcsrepo'
I write url for repo, then puppet do (git clone| git pull) and ( git submodule init | git submodule update), and its look good for me.
Logic is : if you have git repo, all subrepo must be submodules, not new git repo with unknown url.

Why you do echo ".vim/bundle/" >> .gitignore ?
I want to have full copy of my repo after clone this.
I do it once, push into my public repo, and its deployed on all my servers.
With ignore, after that i must login on each server and do some commands for update? thats annoying.

[ghost]

So then why use Vundle in the first place if you're using submodules in that way? Also an option would be to run vim +BundleInstall +qall from puppet on the server after cloning git repository?

[korjavin]

Why? Erm. Vundle is pretty nice and i like it, thats why ;)

Its do wrong only one thing ("git clone" instead "git submodule add" if .vim contains .git).

And i just want to help Vundle be better.

Yes, for now after :bundleinstall, i do boring 100 steps. git remote -v, remember url,rm -rf , git submod ... , git commit , git pull etc. Its solve my problem, but really boring.

[ghost]

Thing is that it would require Vundle to: add the bundles as submodules, commit those changes, update the submodules with the update command and commit those new versions too, etc.

This would make it far more complicated than it is now. You could make an easy bash script to do the submodule adding for you probably.

[deiga]

I have a similar setup to yours. I just added vim/bundle/* to .gitignore and made an installer script which clones vundle into vim/bundle/ and then runs vim +BundleInstall! +qall

[jdevera]

As I said earlier, this is a matter of preferences, I suppose. I also have my .vim directory under git but I do what @deiga just said. If vundle assumed that I wanted modules, not because I say so, but because I happen to have my .vim under .git, I'd be annoyed, tbh (have you tried removing a module? it's a pain).

I still believe it makes no sense to use vundle and submodules at the same time. Vundle is all about keeping everything up to date, submodules are all about locking into a specific version. Actually, once of the planned features to add to vundle is to lock certain plugins in a specific branch or tag or commit, which would then make submodules even more useless.

With submodules, you are doing the work, without submodules, vundle does it for you.

I think if somebody really want to have their submodules, they should use simpler tools like pathogen, that do not interfere with the version control at all, they just add stuff to the rtp.

So, I don't think we'll replace the current cloning with submodules, especially not as a default or as a inference from some condition that happens to be true for some users, e,g., .vim is under git. If we end up supporting submodules, it will be by explicit request somewhere in the config. In the meantime, I recommend trying out the solutions presented here (they are all the same solution, to be honest).

[ag4ve]

What I had imagined when I first made the request is a variable in .vimrc
that vundle used to determine if it should use the default of grabbing new
repos or using submodules. I wouldn't want to change expectations or break
any existing setup, just add on.

On Tue, Feb 19, 2013 at 10:44 AM, Jacobo de Vera
notifications@github.comwrote:

As I said earlier, this is a matter of preferences, I suppose. I also have
my .vim directory under git but I do what @deigahttps://github.com/deigajust said. If vundle assumed that I wanted modules, not because I say so,
but because I happen to have my .vim under .git, I'd be annoyed, tbh.

I still believe it makes no sense to use vundle and submodules at the same
time. Vundle is all about keeping everything up to date, submodules are all
about locking into a specific version*.

With submodules, you are doing the work, without submodules, vundle does
it for you.

I think if somebody really want to have their submodules, they should use
simpler tools like pathogen, that do not interfere with the version control
at all, they just add stuff to the rtp.

• Actually, once of the planned features to add to vundle is to lock
  certain plugins in a specific branch or tag or commit, which would then
  make submodules even more useless.

So, I don't think we'll replace the current cloning with submodules,
especially not as a default or as a inference from some condition that
happens to be true for some users, e,g., .vim is under git. If we end up
supporting submodules, it will be by explicit request somewhere in the
config. In the meantime, I recommend trying out the solutions presented
here (they are all the same solution, to be honest).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/226#issuecomment-13779066.

[kevinSuttle]

Just stumbling upon this thread.

I've been keeping my .vim/ as a list of git submodules in my dotfiles repo.

https://github.com/kevinSuttle/dotfiles/tree/master/vim/.vim/bundle

This works well. I clone my dotfiles, run the setup script, git submodule init && git submodule update and I'm golden. I do use Pathogen admittedly ( ow, not in the face ). Seeing Vundle just clones a repo made me wonder, so I came here to find out why. :)

[nichtich]

Why not supporting this as an option? The benefit of submodules is to track exact versions of plugins (while vim +BundleInstall +qall always installs the latest version) and being able to clone everything with one command (git clone --recursive). The disadvantages are submodules are already mentioned, so it should be an option.

[kevinSuttle]

Since I posted my original thoughts above, I stopped tracking my /.vim/ directory in my repo. Vundle makes dealing with Vim plugins a much more elegant and less contraining task.

[korjavin]

Keep ./vim in git have additional abilities. I do easy deploy .vim with puppet/git.

[kevinSuttle]

Very true, but that's not an advantage that the /.vim directory provides, so much as an advantage of using Puppet. You can automate the Vim plugin installation through Vundle and your shell of choice with 3 lines of code (and that's taking the long way around).

https://github.com/kevinSuttle/dotfiles/blob/master/install.zsh#L16
https://github.com/kevinSuttle/dotfiles/blob/master/install.zsh#L19
https://github.com/kevinSuttle/dotfiles/blob/master/install.zsh#L20

[korjavin]

@kevinSuttle yep. But it not the same.
I deploy all my dotfiles by git, its alot of repos, scripts, settings, etc etc, and only for vim I need different bicycle.

[constfun]

Allow me to humbly offer my opinion:

I have vim/bundle in .gitignore and I very much like the fact that vundle doesn't use submodules. This is my primary reason for using it instead of pathogen.

With vundle, installing/updating plugins is separate procedure from changing other vim configurations.

I have no desire to "track" a submodule for every single plugin, no desire to deal with submodules every time somebody updates a plugin. When checking in my dotfiles configuration, I am only interested about what I changed in my setup. Having submodules, with pathogen, was a pain, because I would change one line in my vimrc and do git status and get a list of a dozen submodules that 'need to be udapted and checked in.' I just don't care. Manage my plugins and get out of my way.

[steveno]

@pacemkr +1

[maljub01]

I'm currently maintaining a fork of vundle that adds git submodule support, with a pending pull request. It's been working great for me so far.

Being able to control which version of a plugin you use makes it much easier to figure out when updating your plugins breaks things for you. I usually only commit the updated submodules after using them for some time and making sure that the update didn't break anything. In some ways, using submodules is sort-of like committing your Gemfile.lock in ruby projects.

Nevertheless, the arguments mentioned above against using submodules are all reasonable. Honestly, it all eventually comes down to personal preference.

I think a good compromise would be to use submodules if .vim/bundle is managed by git (ie. inside a git-managed directory & is not ignored), but use git clone normally otherwise. This way vundle can provide submodule support without forcing them on those who wish to simply ignore their .vim/bundle directory.

I just implemented this in my fork. Trying to add a submodule to an ignored directory would've been a potential bug anyway. Please if you're interested check it out and help me iron out any remaining bugs or edge-cases, even if only by trying to use it and reporting any bugs you encounter.

Thanks 👍

[korjavin]

@maljub01 nice!

[deiga]

@maljub01 The same functionality without the actual submodules would be covered by this feature #267

[maljub01]

@deiga #267 and #116 both allow for tighter control over plugins and their versions. However, I still think submodule support should be added so vundle wouldn't mess up your git repo if you chose not to ignore .vim/bundle, and because it has some other benefits that have been mentioned earlier in this thread. Again, it all eventually comes down to personal preference.

Still, I would like to see #253 implemented in vundle, and #267 goes a long way towards that.

[MarcWeber]

might be related #292 (version lock file). Now git also supports subtrees (which is somewhat related to submodules). The allow to import foreign repositories into your own - and update in some way. Thene there is no need to git submodule init etc. Changes can be "exported" to the original repositories. see #198

[Robsteranium]

It looks to me like #185 allows you to bootstrap your vundled-vim by ignoring your bundle directory, adding vundle itself as a submodule, and then letting vundle manage the other plugins:

cd ~/.vim
git init
echo "bundle" >> .gitignore
git submodule add -f git@github.com:gmarik/Vundle.vim.git bundle/Vundle.cim
git add .

The add . allows you to pick up non-vundle-managed config (e.g. .vim/indent/ruby.vim) including (with vim 7.4) a .vim/vimrc!

Then one you've cloned this you can just do vim -c ":BundleInstall" and vundle will grab all of your plugins for you. No need to worry about managing submodules for each plugin - your vim git repo only need change when you edit your vimrc or add any manual configuration.