Re: [PATCH 6/6] push: honor branch.*.push

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2013, 15:41 UTC
Message-ID: <7vy59zbjns.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kqyV+MTW8jDDBt-qEB1R7yvD+n4nTxwvW0QjA13J2=2A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 14 quoted lines

> Junio C Hamano wrote:
>>>   # on branch master, derived from origin
>>>   $ git push ram
>>>
>>> And branch.master.push is set to next?  Will you let her shoot herself
>>> in the foot like this?
>>
>> It is not shooting in the foot, if branch.master.push is explicitly
>> set to update next.  I do not see any issue in that part.
>
> The question does not pertain to master being mapped to next; it
> pertains to central-workflow versus triangular-workflow: origin versus
> ram.  If the user has set push.default to upstream, she _expects_
> triangular pushes to always be denied,...

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.

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?

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