Re: [RFC/PATCH] push: introduce implicit push

[John Keeping <john@keeping.me.uk>]

On Mon, Apr 15, 2013 at 02:29:29AM -0700, Junio C Hamano wrote:
>  - Your "branch.*.remote only kicks in when I do not say either what
>    to push or where to push to, so 'git push -- master' won't be
>    affected" could be one valid natural extension to your knowledge
>    "the config only kicks in when I do not say either".
> 
>  - Peff's "'git push' chooses to push to branch.next.remote when I
>    am on 'next', so 'git push -- master' run in the same state
>    should also push to that place" is another equally valid natural
>    extension to his knowledge that "'git push' chooses to push to
>    branch.next.remote when I am on 'next'".
> 
>  - Ram's and my "branch.master.remote is about what remote my master
>    branch integrates with, so no matter where I am, 'git push' that
>    does not say where-to should push out my master to that remote"
>    is yet another equally valid natural extension to our knowledge
>    that ""branch.master.remote is about what remote my master branch
>    integrates with".
> 
> I do not think it is a red-herring at all. It is not about
> "breaking", but "there will be multiple, conflicting and equally
> plausible expectations" that makes me worry about unnecessary
> confusion.

Okay, I think it's a red herring from my point of view that "this is
something new that is very different from the current functionality",
but as you point out, "no arguments vs. some arguments" is only one
potential internal model of the current behaviour.

So the question is "what is the natural extension of the current
behaviour?", and the answer for me is "it's completely new", but others
have different (and conflicting) internal models that give different
answers.