Setting a plugin's branch explicitly cause :PackerSync to "unshallow" the plugin

[oblitum]

A shallow clone happens on initial install only (initial :PackerSync). Later :PackerSyncs cause unshallow of repos, pulling them a second time, it's rather annoying and can bloat the disk with unnecessary commit history.

[wbthomason]

We run the fetch command, which has a non-shallow depth specified by default, when a branch, tag, or commit has been set. Perhaps we can be smarter about only running this if we don't already have a reference to the required branch?

[oblitum]

@wbthomason I don't know the codebase, so in thesis that seems ok to me.

[carlosala]

Hi @wbthomason! I would ask how is everything going here. Maybe for updating a plugin that we chose a particular branch we can just pull that branch, instead of fetching all the repo. I think would be quite interesting. For example, coc.nvim goes from 7.9MB to 58MB after unshallowing. It's quite a lot!

[EdenEast]

On a related note, if we knew a commit's date we could take advantage of the --shallow-since option for clone, fetch and pull. This is part of my feature proposal for integrating a lockfile into packer #1009.

[carlosala]

Maybe we could check how vim-plug does this. I think when I was using it the clones were shallowed.

[justinhj]

Chiming in because I was looking into this myself. You can see Plug's behaviour wrt to shallow cloning in the test suite test/workflow.vader#L1536 Shallow clone is the default unless you disable it globally with g:plug_shallow = 0, or if the user specifies a tag for the Plugin (but not a branch). Finally shallow clone is disabled for non SSL repo's (anything over http not https).