I imagine this would be a flag to follow go <cmd>, such as go build -C dir or go test -C dir ./.... I don't think the root go command has ever taken flags directly, so it would be odd to break that rule - unless we deem this flag special enough. Note that we already have common flags between some commands, such as -modfile or -x. I also imagine some commands may not need this flag, such as go version or go bug, but perhaps I'm wrong.

As for the logic itself: would it effectively replace the use of the current directory everywhere? For example, if I do go build -C /new/dir -o cmdbin foo.com/cmd@latest, would the binary show up in /new/dir/cmdbin or in ${PWD}/cmdbin? I would imagine the former for the sake of consistency; just like what a real pushd/popd pair would do. Note there are plenty of other flags that accept relative paths, such as -modfile or -overlay, so we need to think about them all together.

I think I'm neutral on this proposal. On one hand, it seems like a harmless addition, and there is indeed precedent in other popular tools. On the other hand, it's hard to judge how necessary the flag really is, and it does seem like a pretty far-reaching flag compared to the other common flags we have right now.

What particular use case are you thinking about? What is the particular problem with pushd/popd, the verbosity of it?

The main use case is to avoid the constant refrain of pushd path/to/foo >/dev/null; to do whatever; popd >/dev/null in scripts (even worse if I need the exit code from go) and to make it more like the other tools.

You could use a subshell, which is a lot shorter than pushd/popd (or even the quietier cd foo; cd -) and do give you back the exit codes.

$ (cd foo; pwd; true); echo $?
foo
0
$ (cd foo; pwd; false); echo $?
foo
1

I most commonly do this with my Go checkout to run make.bash from my repo root: (cd src; GOGC=off ./make.bash).

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

If -C is really "do a chdir before anything else", then that's easy. But what about

go build -C bar -o x.exe 

or worse

go build -o x.exe -C bar

Does that x.exe get written to bar/x.exe? What behavior will people expect?

It sounds like the suggestion here is that this command writes to bar/x.exe.
Will that be too confusing for people?

/cc @matloob @bcmills

@matloob @bcmills, any thoughts on adding -C meaning exactly

go cmd -C dir ...
==
(cd dir && go cmd ...)

where the parens make the shell switch back when go exits.

?

Being nitpicky here, but I assume we'd want to make it equivalent to (cd dir && go cmd ...)? like if dir doesn't exist, go should bail with a non-0 code.

This would be a nice, small change that is consistent with other tools like git and would help simplify build scripts.

I worked on some build automation last year on a previous team that had most of their code in a monorepo. All of the build instructions and scripts were littered with pushd/popd or the equivalent cd dir && go … && cd .. pattern. This added a bit of visual noise and in some cases was error-prone when directory structures were refactored as the relative paths in cd .. needed updating. In those same scripts, git repositories outside of the main monorepo were interacted with using git -C.

I've seen some Makefiles in Go projects that followed patterns similar to this that would have also benefitted:

GOCMD=go
GOBUILD=$(GOCMD) build
BINARY_NAME=app

build: 
  cd dir; $(GOBUILD) -o $(BINARY_NAME) -v

The directory traversal was typically handled with something like that or $(MAKE) -C dir but having the Go tooling handle the directory change without needing to worry about using a subshell or invoking Make is a little easier to work with. For both shell scripts and Makefiles, I often see counter arguments raised that "you could just do x!" which are often technically correct but less friendly to developers who may not be as familiar with some rough edges in both areas. In that sense, a go -C flag would likely be easier to use for a wider range of backgrounds and experience levels, which I think is a good thing.

Any objections to adding this?

I tried to think of whether any existing cmd/go behaviors might intersect poorly with this, and did not spot a glaring serious conflict.

For example, go build takes -modfile that allows selecting an alternative go.mod file, which is okay to do at the same time as using another working directory.

Presumably, it'd also be possible to set -C via cmd/go's GOFLAGS environment variable, possibly configured in environment or via go env -w. Since the go command doesn't use the current working directory while looking up go env GOENV, it doesn't conflict.

Edit: Also, go test and go doc have boolean -c (lower case) flags. They do not conflict since this proposal is about -C (upper case).

I'd be interested in working on this if there are no objections to the proposal and no one else has picked it up yet.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

You could use a subshell, which is a lot shorter than pushd/popd (or even the quietier cd foo; cd -) and do give you back the exit codes.

I also reached for that solution in a GitHub action and then found that it failed on Windows: it would accept the syntax, but then ran the following commands in the directory of the subshell.

So +1 from me for the proposal.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://go.dev/cl/421436 mentions this issue: cmd/go: add -C flag

YAY! Thanks all.

Change https://go.dev/cl/449075 mentions this issue: doc/go1.20: add release notes for cmd/go changes