if the repository owners tags a commit with the tag Go1, it is used by Go. If there is no tag to specify which commit, the tip of master is used. In practice, most maintainers just keep master clean and do all development in a dev branch.

I hit this a while ago. The first thing I tried to install failed, because it depended on something that depended on something that moved its repository location (renamed itself from foo.go to foo).

It's a convenient hack but nothing more.

If I wanted a specific tag or release, I would just download that revision in the GOPATH directories, and refer to the package directly, instead of through the github URL.

Kind of a clunky way to handle versioning though. In Lein (for example), adding

    [noir "1.2.0"]

ensures I'm always grabbing the same version. In Go, appears the only way to guarantee this is to check in the full source of the library alongside your own in your repo.

I wish Leiningen would also handle bleeding edge dependencies as easily as rebar eg:

    {deps, [
      {quoted, "1.0.3",
        {git, "git://git.corp.smarkets.com/quoted.erl.git", {tag, "1.0.3"}}},
      {proper, ".*",
        {git, "git://git.corp.smarkets.com/proper.git", {branch, "master"}}}
    ]}.

This plugin[1] looks like what you're looking for.

[1] https://github.com/tobyhede/lein-git-deps

"You will also need to manually add the checked-out project's dependencies as your own (the plugin simply checks out the code, it doesn't recursively resolve dependencies)."

I've seen this plugin before but its not particularly useful without dependency checking. It's a start though. I'll have to look at leiningen to see if it exposes hooks for that sort of thing.