Vendored submodule inception use case

[samv]

In the case where you're vendoring a library which has vendored dependencies, building on the master project can cause problems (particularly if the vendored library shares types from third party libraries with the outer project). Go prefers to use the inner vendored directory, and sees either empty directories or cloned checkouts, depending on whether you cloned recursively or not.

I know that the standard approach for this is to not vendor dependencies in libraries, but I feel that forgoes some of the benefits of submodule-based vendoring (eg, build reproducibility & keeping change history for dependencies in one place, convenient per-project GOROOT automatically checked out by git submodule update, documenting the last tested version of a dependency, not necessarily breaking your workflow when a library makes an API incompatible change, etc).

Instead it should be super easy to ignore the library's vendoring and bypass it for a higher level project. This fits well with git submodule-based approaches to vendoring; whoever checks out the library can choose whether to use the vendored dependency with a recursive clone, or to rely on the master vendor directory.

My approach is to run this after git submodule update at the top level of each working tree:

git submodule foreach 'git submodule status | grep vendor | while read junk dirname
do
     [ ! -d "$dirname" ] || (echo "nuking `pwd`/$dirname"; rm -rf "$dirname")
     git update-index --assume-unchanged "$dirname"
done'

This seems like the sort of thing it should be possible to do more easily from vendetta. Any thoughts on the problem, solution or whether patches for this would be welcome?