With `glide install --strip-vcs` vendored directories are treated as submodules

[j16r]

After performing

glide install --strip-vcs

Glide packages my dependencies into vendor/ and removes the accompanying .git directories. Unfortunately the next person to use git submodule update now gets an error:

No submodule mapping found in .gitmodules for path ...

With the following command:

git ls-files --stage

You'll get something like this

16000 f1c275a2c77d480844ac10d58e550a05ee0595c7 vendor/github.com/streadway/amqp
...

This 16000 flag number indicates that git should treat these as submodules, even though there is no entry in .gitmodules. This can be fixed with git rm --cached -r vendor && git add vendor, but that's not really an ideal experience.

I suspect we may be able to avoid it by using more appropriate commands when using git to clone.

[mattfarina]

Note, if you strip vcs the .git directories will be removed. How is it seeing anything to treat as submodules?

Do you have the vendor/ directory in your .gitignore?

Some changes will be coming in the next release to remove this issue.

[j16r]

Hey @mattfarina, no vendor/ is not in my .gitignore. Regardless, all of vendor is in fact checked in - other people who clone the repo get the files.

[dudymas]

wouldn't it be fair of glide to write a .gitmodules file?

[sdboyer]

@dudymas I don't think that'd be a good idea. The .gitmodules file is basically a less capable version of glide.lock (in that it only helps with git-based dependences).

Also, submodules induce a rather specific workflow. Trying to have glide support both a with-submodule and without-submodules workflow would just muddy the waters for everyone. That's especially true, given that the feasibility of using submodules could change without warning due to just a small shift in the depgraph - whoops, a new transitive dep, and now suddenly there's some bzr mixed in there!

Writing a glide plugin could be a way to do it, but IMO, it'd be opening a can of worms to have glide itself support writing redundant information out to disk in order to support one specific (and not really encouraged) workflow.

[sdboyer]

Oh, and also because, using submodules isn't likely to work at all after #384.

[kevin-cantwell]

I'm also seeing this behavior. Running git ls-files --stage | grep 160000 (160000 indicates a gitlink, which is used to create submodules). However, there appears to be no way to remove the gitlink and just check in the damn files. Or at least, I'm not good enough with git to do so...