@bcmills

@maeglindeveloper: There might well be a better answer, but I think one approach would be to run go get myrepo2@dev in myrepo1 just before you want to test myrepo1. I suspect that would update the go.mod file in myrepo1 to record the current meaning of the dev branch for myrepo2 as a pseudo-version in the corresponding require directive (without you needing to have tagged myrepo2 just before testing, which I think is part of your concern).

I have not tested your specific case before, but some related snippets from the documentation:

The go command accepts a "module query" in place of a module version both on the command line and in the main module's go.mod file. (After evaluating a query found in the main module's go.mod file, the go command updates the file to replace the query with its result.)

and (with emphasis added):

A revision identifier for the underlying source repository, such as a commit hash prefix, revision tag, or branch name, selects that specific code revision. If the revision is also tagged with a semantic version, the query evaluates to that semantic version. Otherwise the query evaluates to a pseudo-version for the commit.

and:

go get github.com/gorilla/mux@master # records current meaning of master

Those snippets are from a few different sections of the doc, but this section is perhaps most relevant:
https://tip.golang.org/cmd/go/#hdr-Module_queries

Sorry if that is off base, but what do you think about trying that?

@maeglindeveloper and there is a little more background here:

https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies

I think part of the intent of modules is:
"Day-to-day adding, removing, upgrading, and downgrading of dependencies should be done using 'go get', which will automatically update the go.mod file."

In addition, my understanding is the default behavior of a go.mod file is that it locks the versions of dependencies into place until some other action occurs (in order to have reproducible builds).

Taking all of that together, maybe it is not crazy that go get is a mechanism to tell one of your modules to update which version of your second module should be used at a given point in time?

(And go get is one option, but I think a more-or-less equivalent option is editing the go.mod directly to include the @dev module query, which I think then would be automatically converted and recorded back to the go.mod file as a pseudo-version... Between those two workflows, it would then depend whether you prefer to run a command like go get vs. edit a file).

Note that go mod -sync does not update dependencies. We renamed it to go mod tidy, which hopefully will be less confusing in that respect. go get -u is what updates dependencies, or just 'go get dependency-name', which defaults to @latest.

The command you want for an explicit update right now is just

go get myrepo2@dev

I've been thinking for a while about whether to have a special comment in the go.mod that means "when you update, look for this branch", in which case you could use go get -u instead, but of course go get -u would do all dependencies. If you really just want myrepo2, then go get myrepo2@dev at least clearly expresses that.

The tricky part about a “use this branch” annotation is transitive dependencies.

If module A depends on B and C, and B depends on D@master, and C depends on D@dev, what should happen if I go get -u within A?

For replace directives, at least there is a clear answer: we use whichever branch A specified explicitly, and otherwise we use the master branch.

So I think if we support this sort of branch redirect, it — like replace — should be local to the module in which it appears.

We definitely can't respect those annotations in dependencies. We might respect an annotation like that in the current go.mod.

Linking back the other way, I think this is probably related to/dup of #26853

go get -u myrepo2@dev

This doesn't seem to work right if there is a replace directive.

In our case we need to support the use of Gitlab subgroups, so we have to use a replace directive like:

require gitlab.acmecorp.uk/foo/bar/project v0.0.0-20190225143601-609ef8e30e26
replace gitlab.acmecorp.uk/foo/bar/project => gitlab.acmecorp.uk/foo/bar/project.git  v0.0.0-20190225143601-609ef8e30e26

Using go get -u gitlab.acmecorp.uk/foo/bar/project@master will change the go.mod file so it's:

require (
    gitlab.acmecorp.uk/foo/bar/project v0.0.0-20190225143601-609ef8e30e26
    gitlab.acmecorp.uk/foo/bar/project.git v0.0.0-20190225153601-12312312312
)
replace gitlab.acmecorp.uk/foo/bar/project => gitlab.acmecorp.uk/foo/bar/project.git  v0.0.0-20190225143601-609ef8e30e26

At least it's generating the version string so I can copy that into the right place, but usability-wise it's a bit of a nightmare.

@Xiol, the behavior you are describing is #28176, but the particular use-case (resolving an import of /git to the repository at /project.git) is better suited to go-import tagging than to replace directives.

I have a same problem. But I fixed it by making sure there are no Go files using or refer to master.
I hope it can help you too.

I'm using OpenAPI Generator trying to merge different language SDK into same repo,that cause I need go get can track on specified branch or it will take the wrong commit or tag with other language....