Also, forgot to mention that we used Git's pushInsteadOf feature to work around this for Rob's specific cases (see the gitconfig and git-push man pages), but it seems like a more general fix would be useful for other people since pushInsteadOf is fairly simple and won't work in general for this problem.

@adg, @bradfitz and @rsc are sure to have opinions on this.

Doesn't seem worth the complexity.

I don't know that git think you mentioned, but you could also just write a program to scan your $GOPATH and convert any origins from their public to auth-required URLs. At least that program would stay out of cmd/go.

It's not just a one-shot problem. It's an ongoing thing. Once you've got this kind of package in your $GOPATH, go get -u forces you to use the canonical remote, which needs to be the public one, which makes it worse for the developer wanting to push. I guess you could tell them that they can't use go get -u on packages they develop, but that seems lame.

It's not a lot of complexity. The implementation would be a trivial bit more parsing (strings.Split on spaces, then do a containment check instead of using ==), and it has zero impact on import tags that don't care about it.

The git url.pushInsteadOf configuration is to solve this kind of problems.

@minux: Please read what I wrote on #9532 (comment). That's an incomplete solution.

Why it's incomplete? Only the author of the package need to set up
pushInsteadOf and then use the canonical clone URL.

Everyone who wants push access to a repo needs to do it, and it needs to be done on every machine that has a checkout. That's M*N instead of 1 (a single change in the meta tag). In the simplest case, yes, it'll be a fine workaround when M=N=1, but it's kinda clunky to do that to work around a deficiency in the go tool.

David, even with your proposal, each author needs to independently configure the git origin from http to ssh once, no? I guess you're fine with that, but just want the tool to stop complaining thereafter? But if you're already fine with the user having to configure the repo to commit elsewhere, maybe instead we add a mechanism to shut up the warning... some sort of "yes-i-know-you-don't-like-this-location-but-it's-cool-trust-me" flag. Then if the upstream URL for authors is secret (e.g. some internal corp URL), you don't have to leak it publicly too.

That would be fine with me too.

I'm concerned that relaxing the check will make vanity import
checking useless. (A check that can be disabled is equivalent to
no check at all, people will disable it. That's why we don't offer
flags to disable "annoying" unused variable/import errors.)

The author of a package always need to do something special for
the git repo to be able to push anyway: be it another go get
flag (and he also needs to clone from another location) or
git config (remote.origin.pushurl, or branch._.pushremote), so I
don't think the extra cmd/go flag or extra remotes in meta tag
could solve the O(M_N) problem. (unless we make go get somehow
clone from the git: URL by default.)

I just checked that the author can simply set
git config remote.origin.pushurl git@github.com/robpike/filter.git

and then he can push without problem, and go get -u won't bark,
this is a per-repo setting, so i think it's better than the pushInsteadOf
workaround (unless you have multiple clones of the same repo.)

On 9 January 2015 at 11:32, Minux Ma notifications@github.com wrote:

I just checked that the author can simply set
git config remote.origin.pushurl git@github.com/robpike/filter.git

and then he can push without problem, and go get -u won't bark,
this is a per-repo setting, so i think it's better than the pushInsteadOf
workaround (unless you have multiple clones of the same repo.)

That did not work for @robpike yesterday, which is what started all this.
If it's meant to work then there's a bug in the go tool, because it was
definitely failing for him.

maybe instead we add a mechanism to shut up the warning

It exists. "go get -u -f"

I just created a clone of the filter repo, and tried this:
git config remote.origin.pushurl git@github.com:minux/filter.git

And git push worked for me.
(Note the colon, not slash, after github.com)

Oh, I missed you were setting .pushurl instead of .url. Yeah, that's an equivalent workaround to the pushInsteadOf config, except that now you need to do it for each repo instead of potentially just once in your $HOME/.gitconfig.

Right, but as I said earlier, the author always need some
special handling to be able to push, so each workaround
is as good as others.

This is similar to #9300 and all the other issues requesting
support for git ssh remote URLs.

Unless go get supports cloning form the ssh URLs, I don't
think we can get rid of the special handling for package
authors.

Not worth the complexity.