Re: [ITCH] Specify refspec without remote

Jeff King wrote:

Maybe. But no more so than the current:

  git push

which may also push master and next to the same remote.

I would argue that this was not really a problem in practice, until I
introduced branch.<name>.pushremote.

Let us imagine that I was working on artagnon/git.git (remote: ram), a
fork of git/git.git (remote: origin) earlier.  My fork contains the
link and implicit-push branches in addition to the master, next and pu
branches, which are present on both.  When I push from my
implicit-push branch with push.default = matching, I'm updating all
the matching refs on the remote ram (since branch.implicit-push.remote
is set to ram), which is fine.  Now, I git push while on branch
master.  My push is simply rejected, as I don't have write access to
the remote origin.

This is designed exactly for the read-only upstream, read-write fork
scenario.  If I had write access to upstream (where we're essentially
regression to a centralized model), we'd have some major confusion.

As I said in an
earlier message, I would be OK with allowing both or neither, but
allowing one but not the other is even more confusing.

What is the point of allowing something internally consistent, but
nonsensical?  You should complain.