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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to