Junio C Hamano wrote: > If the user said "git push" without an explicit request to push to > "ram", and if branch.master.pushremote was not set to "ram", and > still the command "git push" pushed the branch to "ram", then I > would understand what you are worried about, but otherwise I do not > see how what you are saying makes sense. We currently have no system to differentiate between those two cases. > A safety valve is different from a straight-jacket. If you are > working largely with a central repository and have push.default set > to upstream, are you now disallowed to push out things to other > places to ask help from your colleague to check your wip? Why? I've been harping about how this safety valve is poorly done, and I'm the first person interested in loosening it. But I do not think this is the way to do it: drop in branch.<name>.push magic, and make upstream suddenly work with triangular workflows? > Or are you saying that with push.default set to upstream, only these > two forms should be allowed? > > $ git push ;# no destination, no refspec > $ git push there ref:spec ;# both explicitly specified No, no. What I meant is: From the documentation of push.default, I _expect_ upstream to kick in only in the first case. In the second case, I _know_ that my push.default is inconsequential. With branch.<name>.push magic, you've sneaked in a push refspec under the carpet, and the first form suddenly doesn't care about push.default anymore. remote.<name>.push is also an under-the-carpet implementation that I don't like: it's done in push_with_options() which can completely bypass setup_default_push_refspecs(), shooting the user in the face. I want properly defined precedence and well-defined overall behavior. Not sneaky stuff. I don't have an answer, but will start a discussion with some code soon. In the meantime, since we've already figured out this series, merge it without 6/6. Thanks. -- 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