driusan

I see where you're coming from and agree that commit IDs aren't very friendly, but from a technical perspective it solves the same problem of having dependencies on specific versions of software.

Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.

Submodules in git specify the specific commit to be checked out and don't automatically track the HEAD of a branch (unlike go get.)

That's why I include the statement that Go vendoring is useful "(at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)"

I don't think it's as obscure as a problem as you think.

I've been trying to learn Go as a sideproject for less than a month, and even I realize what the problem is and how the vendor spec solves it (at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)

One of the things I miss the most when working in Go is PHP Composer, and it's pretty obvious how the vendor design doc solves the same problem in a more Go idiomatic way.