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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
