Re: [ITCH] Specify refspec without remote

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 10, 2013, 20:05 UTC
Message-ID: <CALkWK0nAMVKuDg4wmwujkpNxAF9zxQEdsZXyUzr+w4zVpWDCzA@mail.gmail.com>
In-Reply-To: <20130410195256.GA24177@sigill.intra.peff.net>

Jeff King wrote:

Show 5 quoted lines

> 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.