/cc @futabooo

you have got a point.
It may be better to leave it to developers.

below is my opinion.

Any Go developers sometimes static vendoring into vendor directory.
Because for the delete vendoring packages repository, reliably build with
vendor packages or etc

I think it is not good,It is better to use package management

Also, A typical vendoring tool such as gb, gvt will create manifest file on vendor directory.

how about this?

/vendor
!/vendor/manifest

@futabooo

I think it is not good,It is better to use package management
how about this?
/vendor
!/vendor/manifest

Yeah, That is our gopher's ideal. like ruby's gem or any good package manager.
However, Go vendoring manager tools is not stable yet. Still chaotic(?).

Also, If package manager supports the good vendoring feature, still have depends on the existence of the github repository.
I do not know the thought of other developers, but I guess that is probably concerned about the occurrence of "npm leftpad"(at least I am).
Therefore, I did statically vendoring. In other words, including all vendor packages .go file to my repository's vendor directory.

Well, I always delete it and create a .gitignore, so there is no problem. If you do not like it, I will close it :)
However, it certainly has a .go file in the vendor that docker, docker-machine, minikube.

@zchee
Overall agreement:)
I'd like to ask other people's thoughts, so I do not think you need to close it!

Vendoring support is officially supported as of go1.6, which means the vendor directory is recognised by Go project's go build or go install command to build Go code.

There are a number of projects, including widely used projects like docker, which uses the vendor directory. Putting vendor on GitHub's .gitignore will not affect most existing users or those who write their own .gitignore, but Go users who create .gitignore using GitHub's web interface may be confused by the discrepancies between the official specifications and the behaviour of the default .gitignore created by GitHub.

I don't believe this is a matter of personal choice, but should be considered for the consistency between Go project's specification/official tooling support and the expectation of a conservative, default .gitignore. Hence I will strongly support leaving vendor out of .gitignore (i.e. please proceed with the revert).

Closing due to conflicts. @zchee please have a look at the latest file and see if anything needs to be incorporated.