From: Junio C Hamano Date: Mon, 15 Apr 2013 09:29:29 GMT Subject: Re: [RFC/PATCH] push: introduce implicit push Message-ID: <7vk3o416rq.fsf@alter.siamese.dyndns.org> In-Reply-To: <20130415083558.GB2278@serenity.lan> John Keeping writes: > I may be an atypical user, but my expectation currently is that > branch..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.