Ramkumar Ramachandra wrote: > git push -- master next; pushes to my current branch's > branch.<name>.pushremote? Isn't that a disaster? Actually, branch.<name>.pushremote already breaks the current design in a way, as Junio pointed out in a different email: a push.default set to anything except "current" is already nonsensical. Why should "matching" branches be pushed to the remote that my current branch specifies? That might well have their own branch.<name>.pushremote configured, which should be respected. We should fix this now. I think the fault lies in the rather old design of push.default. Do you have any suggestions as what would make sense here? Ultimately, I think a git push; needs to pick remotes for each refspec separately. The orthogonal design is definitely not right in my opinion. As the author of branch.<name>.pushremote, I apologize for not having caught this earlier. I've been using push.default = current for a long time, and don't often think about the other settings. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html