Add: Support for shallow clones

[jdevera]

This is a feature request.

It'd would be convenient to have a user settable global variable that controlled whether the git clone command that is execute to download plugins makes a full clone or the original repo or a shallow copy.

Ideally, this shallow copy would include only the latest revision (--depth 1)

It would be even nicer if whatever the global setting is, it could be overridden on a per bundle basis.

Shallow clones can speed up download time significantly if there are many plugins installed, specially when repos have many revisions.

[randymorris]

I'd just like to add a +1 from me. . I actually think this would probably even be a sane default. You could most likely use the same mechinism as the custom naming uses now to override this option.

[0]

I think this does the trick.

Note that since all the repositories in vim-scripts have a tag for every commit, this change has no effect for them. I was unable to find a way to not clone the commits which have a tag associated with them.

[jdevera]

I think having a simple switch as configuration is a simpler approach that would cover practically all cases. I can't imagine why someone would want any depth other than 1 or the full thing, so I'd suggest something like
let g:vundle_shallow_clones = 1 to set the depth to 1 and a default 0 to clone the full repo.

[randymorris]

@jdevera that wouldn't allow you to fully clone specific repos while shallow cloning others. @0's approach is flexible without being too complex.

[jdevera]

@rson, I probably did not explain what I meant correctly, what I meant is to basically keep the same logic @0 has put in place, only change the control variable name and meaning, from g:vundle_depth which is passed directly as the --depth parameter for git, I suggest having only depth 1 or the whole repo, and have this controlled with a more generic variable name, could be g:vundle_shallow_clone or we could even make shallow clones by default and override with g:vundle_clone_history.

This being a global setting doesn't mean that it cannot be overridden on a per plugin basis, with something like {'history' : 1}

[0]

@jdevera, I feel that in your case, you lose generality with no loss of complexity. With my version, you can specify a global or local depth of 1 to do the shallowest clone, or of 0 to do the deepest clone. Or if for some reason you so fancy (but only if you do), any other depth value to your liking. With your version, you could do the first part (in the exact same manner, but with different names), but not the second.

That said, it's ultimately up to @gmarik, so for the time being I won't make any changes to the code I pushed.

[gmarik]

wow, what's going on here.... )

There are not many options, which makes Vundle simple, which is important, IMHO
And there weren't any complaints like "Vundle is slooooow please fix it"...
So I guess this is low priority feature for now...

But the part with using global variables/naming is kinda important:

what if instead using global variables we'd just pass options:

call vundle#rc({'clone':{'depth': 0}})

What do u say?

[jdevera]

Well, I don't really mind as long as it works :), I guess that kind of nested structure looks more awkward than a global variable, which is a very common method of configuring plugins in vim. However, I am guessing that because vundle has to be called at the beginning of vimrc, it already is a special case and thus the special type of tuning method makes sense.

But really, at the end of the day, what matters is that it works, I don't think a lot of people will use this feature, and those of us who would use it probably don't mind either way.

[gmarik]

yeah, i agree, hashes aren't as readable as global variables...
Maybe : g:vundle#clone#depth = 0 or g:vundle_clone_depth = 0 vs g:vundle_depth ?
Naming is hard! )

[jdevera]

Your second option (let g:vundle_clone_depth = 1) seems more descriptive and less awkward looking to me. I'm guessing the default value would be 0 anyway, right?

[0]

@gmarik, is there anything you disagree with in my pull request other than the naming?

[gmarik]

@0 if your question is why pull request haven't been merged then the answer is that ppl had lots of issues with current features/documentation. Which is a sign that Vundle needs better test suite before adding new features. So it's kind of "feature freeze" for now.
Adding features is fine as long as we are consistent and not breaking anything.

Let me know what you think...

[ches]

I don't really have an opinion on how this should be configured, but IMO a clone depth of 1 should be default. The vast majority of the time people are going to be installing bundles as plug-and-play, saving space and time with shallow clones is a no-brainer. If you want to hack on a particular plugin and contribute upstream and/or push customizations to your own fork, it's trivial to convert a shallow clone to a full one on an as-needed basis.

[gmarik]

That's true, but there's another side:
There's a feature request to be able to specify revision, combining it with default depth:
Bundle 'rails.vim', {'v':'v0.8', 'depth':1}

But don't they conflict with each other?

[0]

@gmarik, the shallowest possible clone gets all branch tips, all the tagged commits, and all their parents, so it would still always be possible to refer to named (branch/tag) commits that way.

Referring to an individual commit by its hash would obviously not work if that commit doesn't exist, but I think this is reasonable for the general case. On the other hand, if you're going through the trouble of specifying a commit hash, you can also disable shallow cloning.