-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how using a specific branch of a repo with go modules interacts with multi-module repos #30851
Comments
|
|
Folding this into #30850. |
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 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 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 |
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 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 That said, this turned out to be a bad idea. Git makes a file for each branch (in We switched from |
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 |
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 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:
Despite branch "v2" being present in the repo. |
@celesteking, that's #29731. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
I believe 1.12 is the latest release
What operating system and processor architecture are you using (
go env
)?go env
OutputDescription
(I'm not following the bug template here because this is more of a documentation issue)
It's not clear how using a multi-module (or single-module-with-go.mod-not-at-vcs-root) repo interacts with trying to get a particular branch.
Noting that the wiki says:
(https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies)
it's not immediately obvious to me how this interacts with multi-module repos, which require prepending the path. i.e. if I do
go get foo@bar/baz/quux
, does Go think that I'm trying to get a module rooted at/bar/baz
, using the branchquux
, or the module rooted at/bar
on branchbaz/quux
?The text was updated successfully, but these errors were encountered: