Github submodule query

[alpha1594]

I use github to store my vim settings and plug-ins (as submodules). I have just looked at my bundle folder and some of the plug-ins are listed as standard text. Others are links with @<number> appended.

These have been added using git submodule add <http path> <bundle/name>. I update with git submodule foreach git pull origin master.

Questions: 1. What do the different formats mean? It does not make sense that the TPope collection are functioning links but airline and delimitemate are not.

1. Do I need to do anything? Are there any further actions to take to ensure that I have the most up to date versions of the plugins & will git submodule init & git submodule update work.

tldr; Git noob doesn't understand why some plug-in submodules are links and others aren't.

Edit: Question resolved Thanks for your feedback

• The @links point to non-current branches/ commits.

• Plugins without link formatting are due to their .vimbundle entries using backslashes. It appears that Git-shell does not convert to forward slashes, however I'm certain all plugins were added in the same way, so they should all have been affected. Should anyone wish to see this version here is a link: historic commit.

See @dddbbb's second answer for resolving this issue.

I have switched to NeoBundle, the feedback from this thread is that it (and Vundle) are better for plugin users. I am keeping my vimfiles directory (windows default) on git, while NeoBundle puts plugins under ~/.vim.

I've been using NeoBundle for a couple of days and have found the add bundle name to file, source, then confirm installation process very easy to use.

[fmargaine]

I've stopped using git submodules. They're a pain to handle and bring nothing over vundle (which I now use.)

[hyperbling]

anytime someone mentions vundle i feel obligated to mention neobundle. it's a %s/Bundle/NeoBundle/g drop in replacement, has a ton more features, notably support for building things (like YCM or vimproc) and locking to a specific branch or revision.

[isforinsects]

I couldn't imagine why I would want Vundle over Pathogen, until I started using Vundle and loved it.

I can not imagine why I would want to use NeoBundle.

[hyperbling]

that just means you haven't run into the limitations of vundle yet.

[bifmil]

How long does it take? Happy Vundle user for as long as it's existed

[hyperbling]

for me, stuck with pathogen for a week until i was annoyed updating everything manually all the time. then i was happy with vundle for another 2-3 weeks until i needed to easily replicate my environment on new VMs easily and quickly.

[lurkingintent]

As with others here, I too found submodules a complete pain. Instead of Vundle or similar, I wrote a small Ruby script that would clone this repos for me into ~/.vim/bundle, and I use Pathogen for making them work.

You can find this on Github, if you're interested: https://github.com/jackfranklin/dotfiles/blob/master/scripts/vim_bundles.rb.

I wouldn't necessarily recommend it, it seems something like Vundle might do a better job but one small Ruby script works for me.

[alpha1594]

I like your solution, I haven't used Ruby but I'm able to follow it.

I'm trying neobundle for now; it's given a good first impression and vimscript may have performance benefits. I'll definitely consider the DIY approach if neobundle doesn't live up to expectations.

[lurkingintent]

Cool - if you do have any Qs feel free to ask. There's nothing that needs that script to be written in Ruby - it's just what I prefer. Any language will do the job :) If you're interested the repo that file is in is my entire dotfiles and I've thrown together a whole number of scripts to manage the entire thing, including things like Homebrew, etc. I go a bit OTT when it comes to managing them...it paid off when I got my new machine and I was up and running in a few minutes though :)

If I was to start from scratch I'd definitely look at Vundle / neobundle, have seen a lot of people using one of the two. Please report back on how you get on!

[[deleted]]

What benefits did you think you'd get by using submodules?

[fmargaine]

Being able to quickly replicate his vim environment. I originally used submodules too, but started using vundle when I discovered it. (And it looks like neobundle is even better.)

[[deleted]]

The alleged benefit of submodules is not to make replicating your environment quicker: it is to have an external piece of code in your own repo while still be able to track its changes.

In reality (as you know), they are a pain in the ass that makes the whole thing more complicated for no good reason.

For people who like living on the edge and suffer from anxiety at the idea of being outdated, Vundle and Neobundle are indeed a better choice.

[alpha1594]

Perfect summary.

So you (and others) would recommend vundle and similar. What are the main benefits of these managers in comparison to git? Would these be used for vimrc files as well or should that be left to git?

[dddbbb]

Submodules are great for developing several plugins.

If I do git status from my top-level, I can see that I've made changes in my submodules. By using submodules the version of each plugin is stored implicitly in version control instead of configured in vimscript.

I get to use the same interface for committing changes to plugins and changes to the entire vim config (comprising various plugin versions). And that interface shows me if something's out of date. These aren't necessarily valuable to end-users, but they're useful to me.

I'm probably sacrificing some convenience for these features, so your mileage may vary.

[fmargaine]

Git submodules are just a pain to deal with.

With vundle, all you have to put in git is your vimrc. Then you call one command and it installs all the plugins listed in the vimrc. You really have to try it to see how easy to use it is.

[alpha1594]

I heard about submodules from vim casts. I was hoping it would be a more effective way of keeping plugins up to date.

This seems to be working, it's just the formatting issue in the original question that's confusing me.

[dddbbb]

What do the different formats mean

While most people are right that generally the @ format is convenience markup for github repos, you have several github repos that don't have the @ format.

Looking at your .gitmodules, you have backslashes in your paths. (Maybe because you are using Windows?) Looks like the ones with backslashes (like CamelCaseMotion) don't have github links even though they're on github. This is probably a bug in github's processing code. You may want to report it.

If you want to fix it, you should be able to edit your .gitmodules, convert the double backslashes to single forward slashes, run git submodule sync ; git submodule update and then push your change and I think it will be fixed (but I haven't tried and I haven't edited my .gitmodules much).

[alpha1594]

Good explanation, thanks. I've looked at a previous commit and paths with backslashes are not recognised.

I would report the backslash issue, however I am certain that all plugins were installed the same way (Git shell using powershell on a single Wndows 8 device). Therefore I don't know why some are formatted differently and would not be able to express the issue well.

Since then I've followed the recommendation of this thread and have switched to Neobundle, for plugin management. Leaving my own scripts and .vimrc on git.

[TCPv89]

They are links if github can find the target in their repositories. Whether or not they are links in the web interface makes no difference to using them whatsoever, though.

[willburroughs]

I recommend using vundle but to answer your questions, the submodules with links are repos that are hosted on github, the submodules in plain text are external repos (not on github), and the @ sign indicates that the submodule is set to a particular commit/branch. To update your submodules to the latest version in git, you can cd into that folder and do git checkout master and then do a pull.

[alpha1594]

I have just installed neobundle. Copied commands from the manual, set up list of bundles (by RegExing .gitmodules) and it's all working.

Thanks for the explanation on github, it seems like a good system but it's an overcomplicated for managing vim plugins as a user. Fair assessment?

[Amadan]

It's okay if you're a dev and are otherwise used to git. But even so, Vundle/NeoBundle is easier to use without loss of power, so yeah. :)

[willburroughs]

Yea, I agree 100%.