@rsc I'd like to fix this; I've been doing manual cleanup because of it. However, it means making git-codereview Go-specific and/or introducing some config, both of which you're not keen on. Input?

cc @bradfitz

I have no opinion on this.

I'd be happy to have a list of repos that should close issues on the golang/go tracker.

so we definitely don't want per-repository (optional) configuration file for the
review tool?

Repo-level config files have the unfortunate property that the config
changes depending on the state of the repo. That makes me lean away from
them.

Binary-level config has the unfortunate property that the config changes depend on when people updated their codereview binary.

Yeah but at least the config won't change when you switch branches, etc.

On 29 December 2014 at 11:17, Brad Fitzpatrick notifications@github.com
wrote:

Binary-level config has the unfortunate property that the config changes
depend on when people updated their codereview binary.

—
Reply to this email directly or view it on GitHub
#9273 (comment).

On Sun, Dec 28, 2014 at 6:48 PM, Andrew Gerrand notifications@github.com
wrote:

Repo-level config files have the unfortunate property that the config
changes depending on the state of the repo. That makes me lean away from
them.

We can make the codereview tool always use the configuration file from the
master
branch (or even the origin/master branch), so it's independent of which
branch the
user is in.

(It seems this is how .gitattributes works, so there are precedent on
always using
the configuration from the master branch)

Yeah but at least the config won't change when you switch branches, etc.

In addition to what @minux said, do you expect this configuration to update more than approximately once per year at most?

I don't have a strong opinion.

On 29 December 2014 at 11:29, Brad Fitzpatrick notifications@github.com
wrote:

Yeah but at least the config won't change when you switch branches, etc.

In addition to what @minux https://github.com/minux said, do you expect
this configuration to update more than approximately once per year at most?

—
Reply to this email directly or view it on GitHub
#9273 (comment).

I really miss this feature.

Even though I'm perfect aware that I should use golang/go#XXXX
when sending changes for sub-repos, I still recognize the problem
only after I've pushed the CL. It's just to easy to write Fixes #XXXX
always.

And I also propose that we put it into the commit-msg hook so that
people using git directly will also benefit.