Ramkumar Ramachandra wrote: > Jeff King wrote: >> If we are not going to break the existing behavior, I think it can be >> argued that consistency and simplicity of the rules is important, so the >> user can predict what will happen. But the more we discuss, the more I >> think we should simply change the current behavior (to stop respecting >> branch.* config with "matching"), which just seems wrong to me. Then we >> can be simple and consistent, and do what the user probably intended. > > So there are some push.default options that respect branch.* config > (ie. "current"), and others that don't (ie. "matching"). I would > argue that push.default is badly designed to begin with, so the > solution makes sense to me even if the patch is a bit of hack; we > never guaranteed that the various push.default options respect the > same configuration variables. If we're going to break "matching" anyway, let's break it fully. I propose that we make it respect each individual branch's branch.<name>.pushremote/ branch.<name>.remote and push the branch to that remote. That'll let us design a git push -- master implicit-push; that actually makes sense. -- 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