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

Comments

Projects
None yet
3 participants
@myitcv
Copy link
Member

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

This comment has been minimized.

Copy link

commented Oct 25, 2018

Somewhat related to #26964.

@bcmills

This comment has been minimized.

Copy link
Member

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?

@myitcv

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member Author

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 Nov 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.