Should I commit Godeps/_workspace or is Godeps.json enough?

I'm writing a project in Go to be deployed on heroku, managing dependencies with godep.

When I godep save, I get both a Godeps.json file listing my dependencies with versions and an _workspace/ directory with the source for all dependencies copied in. I'd rather not commit _workspace, all that code's already on github elsewhere. It seems Godeps.json has all the information we need to go get the version locked dependencies at heroku buildpack time.

Several sources recommend committing the full Godeps/ directory, but others suggest it might not be necessary.

The godep docs aren't much help:

>This will save a list of dependencies to the file Godeps/Godeps.json, and copy their source code into Godeps/_workspace. Read over its contents and make sure it looks reasonable. Then commit the file to version control.

Is Godeps.json the file?

Official answer:

From GitHub issue #131:

> The intended use of godep is to vendor dependencies and commit the _workspace directory to version control. See the proposal document by @kr linked in #123 (proposal: http://goo.gl/RpYs8e) As discussed in that proposal, godep used to have a mode (-copy=false) that supported not vendoring the dependencies. My guess is that the ambiguous language in the Readme may be due to that. This mode has been removed as documented in #123.

Here's also godep author talking about his project and ideas behind - Vendoring and Import Path Rewriting

Personal opinion:

I don't think there is a right way to do it.

Committing vendor libs does seem awkward, but it has it's advantages:

• You're not relying on external services (GitHub, etc). GitHub has outages, maybe you have some horrible company policy which prevents you from using it, maybe repository disappears or it's history is rewritten, maybe you're behind firewall (staging/build server), etc.
• Each time there are updates to your deps you get a nice diff of what has changed.
  Which helps when updating to newer version, or just keeping track of changes if you screen code that is being used.

At the end it's up to you to weigh the pros and cons. Personally I cringe every time I have to commit vendor code, but in my Go projects I do. At least for now.

Also companies like Google and Facebook mostly keep everything in one repository and that includes vendor code (or so I've heard).

Interesting article on the topic:
Go Package Management

godep will need the json file in order to read back the dependencies, as shown in update.go.
So that file needs to be versioned.

But then godep would fill the content of godep/_workspace, which means it is a "generated" content: you don't need to version it.

Just add Godeps.json file to the repo, and _workspace to the .gitignore list :).

While your code should be fully included in your repo, dependencies have to be just referenced somehow (godep.json, package.json, git submodule... you choose), and nothing more than that.
The same tactics apply to npm, bower, apt and all other package managers.

Your repo - your things + references to vendor libs (of course, when it is possible, you cannot reference sourceforge zip file).

As @VonC said, we do not want to version vendor libs.