Skip to content
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

cmd/go: support for branch name on local module root directory in replace directive #26853

Closed
myitcv opened this issue Aug 7, 2018 · 4 comments
Labels
FeatureRequest FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@myitcv
Copy link
Member

myitcv commented Aug 7, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version devel +9ef5ee911c Tue Aug 7 14:36:14 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

N/a - working with tip.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN="/home/myitcv/.mountpoints/x/src/myitcv.io/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/.mountpoints/x"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.mountpoints/x/src/myitcv.io/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build953293682=/tmp/go-build -gno-record-gcc-switches"

Currently the replace directive is specified as:

The -replace=old[@v]=new[@v] and -dropreplace=old[@v] flags add and drop a replacement of the 
given module path and version pair. If the @v in old@v is omitted, the replacement applies to all 
versions with the old module path. If the @v in new@v is omitted, the new path should be a local 
module root directory, not a module path. Note that -replace overrides any existing replacements 
for old[@v].

As @mvdan and I were just discussing, when working on a mono-repo with multiple submodules and dependencies between those modules, changes to the submodules will need to be sequenced in such a way that it results in separate commits in the remote VCS.

One way of achieving this sequencing is via separate local branches (that ultimately get merged/cherry-picked/whatever on the remote).

Which raises the question of whether we could/should support a replace directive to a local directory which can also accept a branch name (else the local branch changes would need to be pushed to a remote repo to enable a branch specification, i.e. we can't fully develop offline).

One further nuance would be that a local directory@branch specification would not resolve to a commit, and instead would always refer to HEAD (or equivalent)

I realise this creates an ambiguity with the current old[@v] semantics (because the absence of version on the "old" portion of a replace indicates it will be a filepath), so just wanted to float the idea first.

/cc @rsc @bcmills

@myitcv myitcv added the modules label Aug 7, 2018
@thepudds
Copy link
Contributor

Somewhat related to #26964.

@bcmills
Copy link
Contributor

bcmills commented Nov 6, 2018

when working on a mono-repo with multiple submodules and dependencies between those modules, changes to the submodules will need to be sequenced in such a way that it results in separate commits in the remote VCS.

Multiple tags can apply to the same commit. Why do they need to be separated?

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 6, 2018
@bcmills bcmills added this to the Go1.13 milestone Nov 6, 2018
@myitcv
Copy link
Member Author

myitcv commented Nov 7, 2018

when working on a mono-repo with multiple submodules and dependencies between those modules, changes to the submodules will need to be sequenced in such a way that it results in separate commits in the remote VCS.

Multiple tags can apply to the same commit. Why do they need to be separated?

Indeed you can do everything in a single commit with replace directives as you mentioned before (I'm still not sure how much I like this approach but that's another matter! For some reason it feels wrong, but I haven't explored that any further)

But if you choose not to do everything in a single commit (for review reasons, for example), then this situation immediately arises.

@myitcv
Copy link
Member Author

myitcv commented Nov 14, 2018

I'm going to close this as a dup of #26964; there's more chatter in that issue so it makes sense to keep that one open.

@myitcv myitcv closed this as completed Nov 14, 2018
@golang golang locked and limited conversation to collaborators Nov 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants