John Keeping <j...@keeping.me.uk> writes:
> I may be an atypical user, but my expectation currently is that
> branch.<name>.remote is what is used when I run "git push" with no
> additional arguments.
> This is probably because whenever I add additional arguments (currently)
> I have to specify where I am pushing to.
> So I think breaking user expectations is a red herring here because the
> current behaviour means that users cannot have any expectation of what
> will happen in this case.
The thing is, people _want_ to reuse the knowledge they have already
learned to a situation it does not directly apply to, by finding a
consequence, natural extension of that knowledge, applied to a new
- 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
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
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