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

Reply via email to