John Keeping <john@xxxxxxxxxxxxx> 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 situation. - 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. -- 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