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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html