Re: [RFC/PATCH] push: introduce implicit push
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 15, 2013, 09:29 UTC
- Message-ID
- <7vk3o416rq.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130415083558.GB2278@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
Show 10 quoted lines
> 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.