go get foo@bar/baz/quux would mean “get module foo at version or branch bar/baz/quux”. (As a general rule, you should never have slashes in the version part of your go get command.)

go get foo/bar/baz@quux, however, would mean “get module foo/bar/baz at version or branch quux”.

Folding this into #30850.

As a general rule, you should never have slashes in the version part of your go get command.

Git doesn't seem to enforce this requirement (that there are no slashes in a tag or branch name) anywhere. Is this an additional restriction (albeit not a very onerous one) Go is adding?

No, it's a heuristic to determine whether the thing you're writing as a go get command is likely to be correct.

Technically you could have a branch name with slashes in it. I sincerely doubt that many, if any, repositories containing Go code will have such branches.

Branches with slashes are very common, especially with folks using something like git flow

Yes, branches with / in them are definitely a thing.

Our situation is: we have to run CI for an OSS project, which requires access to secrets, which means that to run tests, we need to push branches to the central repository, because secrets are not exposed to branches in forks. To avoid multiple developers trampling over each other, we make branches of the form <username>/branchname. This is to say nothing of named branch release patterns, and so on.

Branches with slashes are ultra common in workflows. You must be able to isolate a specific branch and even a commit in that branch. An example of this is when a certain forward commit breaks something in a library and you require it frozen in time for whatever reason.

For 4 years we pulled a specific commit of a specific branch for an ORM because anything past would break use cases and this part of the application would not be revisited any time soon by engineers.

Details about / in a branch is as easy as looking up feature branches. - IE: feature/my-feature-ABC-123

In things like Gitlab or other automation tools this allows auto-closing/updating of tickets in other systems as well. Alerting engineers of completion, deployment, etc.

We used to use / for namespacing Git branches at my company, so I guess that's an existence proof that there are indeed repositories containing Go code that have branches with slashes.

That said, this turned out to be a bad idea. Git makes a file for each branch (in .git/refs/heads); if you use slashes in the name, git constructs nested directories. This means that you cannot have two different branches newfeature and newfeature/sub-thing because the directories collide. With a different namespacing character, this isn't a problem.

We switched from / to . a couple of years ago and that has worked well for us.

The problem with making those types of changes is that organizations of hundreds / thousands of engineers can't switch code bases, tooling, and existing setups for hundreds of repositories in any timely fashion and to change it because 1 language out of a handful isn't handling it properly seems like crazy talk.

@bcmills can you reopen this? As people have pointed out (and the many downvotes show) this is definitely something people do and something that is a problem with go's 'heuristic' here. Given that it's completely legal and reasonable to have branch names with slashes in them (which several projects that i'm part of mandate), not being able to use the go tooling effectively here is a significant problem.

@CyrusNajmabadi, this is a documentation issue. If you are “not … able to use the go tooling effectively here”, please open a separate issue with steps to reproduce the problem.

Done. Extracted here: #36902

this is a documentation issue.

Personally, i disagree. This came in through 'docs' because people have run into this problem and are looking for the docs to tell them how to get themselves out of it (since the presumption is that the go tooling would certainly not be arbitrarily limiting totally normal git/github practices).

That there is no solution doesn't keep this as a doc problem (and the issue should not have been closed for that reason). The lack of a doc solution should have escalated this into the need for a product fix from the get-go (no pun intended) :)

Interpreting @bcmills more charitably - I think they were saying that this issue - as in, #30851 - was a documentation issue. Thanks for extracting out the issue into a new one.

I agree that branches with slashes with them is not as uncommon a use case as "I sincerely doubt that many, if any, repositories containing Go code will have such branches." would imply though. I recently changed jobs to a large tech company - as in, I am at a different job than I was when I filed this issue - and here, everyone is expected to prepend their username followed by a slash for their branches, and this is done automatically by internal tooling.

That doesn't work:

$ go get github.com/homelight/dat@v2
go get github.com/homelight/dat@v2: no matching versions for query "v2"

Despite branch "v2" being present in the repo.

@celesteking, that's #29731.