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

2013-04-15 Thread Johannes Sixt
Am 4/15/2013 5:04, schrieb Junio C Hamano: Ramkumar Ramachandra artag...@gmail.com writes: ... In my proposal, the precedence order branch.name.pushremote, remote.pushdefault, branch.name.remote, remote.default, origin, remains the same: we just want to change which branch that name refers

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

2013-04-15 Thread Junio C Hamano
Johannes Sixt j.s...@viscovery.net writes: User says: git push -- master docs release Then git pushes the three branches to three different upstreams. You find that confusing. Do I understanding correctly so far? It is far more subtle than that. User says that while on 'next' branch.

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

2013-04-15 Thread John Keeping
On Mon, Apr 15, 2013 at 12:20:32AM -0700, Junio C Hamano wrote: Johannes Sixt j.s...@viscovery.net writes: User says: git push -- master docs release Then git pushes the three branches to three different upstreams. You find that confusing. Do I understanding correctly so far?

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

2013-04-15 Thread Ramkumar Ramachandra
John Keeping wrote: 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

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

2013-04-15 Thread Junio C Hamano
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

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

2013-04-15 Thread Ramkumar Ramachandra
Junio C Hamano wrote: That changing the meaning of name in the middle, and doing so will be confusing to the users, is exactly the issue, isn't it? Yes, but we have to change _something_ if we don't want to hit a WTF like 'git push master next' pushing master and next to branch.HEAD.pushremote.

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

2013-04-15 Thread Ramkumar Ramachandra
Junio C Hamano wrote: 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. Well put. My solution to the problem is to take one of the three

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

2013-04-15 Thread John Keeping
On Mon, Apr 15, 2013 at 02:47:35PM +0530, Ramkumar Ramachandra wrote: John Keeping wrote: 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

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

2013-04-15 Thread John Keeping
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

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

2013-04-15 Thread Felipe Contreras
On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote: 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. I don't

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

2013-04-15 Thread John Keeping
On Mon, Apr 15, 2013 at 11:39:40AM -0500, Felipe Contreras wrote: On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote: 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

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

2013-04-15 Thread Felipe Contreras
On Mon, Apr 15, 2013 at 12:13 PM, John Keeping j...@keeping.me.uk wrote: On Mon, Apr 15, 2013 at 11:39:40AM -0500, Felipe Contreras wrote: On Mon, Apr 15, 2013 at 4:59 AM, John Keeping j...@keeping.me.uk wrote: So the question is what is the natural extension of the current behaviour?, and

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

2013-04-15 Thread Jonathan Nieder
Ramkumar Ramachandra wrote: Junio C Hamano wrote: That changing the meaning of name in the middle, and doing so will be confusing to the users, is exactly the issue, isn't it? Yes, but we have to change _something_ if we don't want to hit a WTF like 'git push master next' pushing master and

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

2013-04-15 Thread Jonathan Nieder
Jonathan Nieder wrote: As you hinted before, this would involve reverting the introduction of branch.name.pushremote, with the explanation that it was a mistake inspired by that false symmetry, that you noticed and were uncomfortable with but the rest of us were blind too. s/too/to/ For the

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

2013-04-14 Thread Jakub Narębski
W dniu 14.04.2013 06:42, Junio C Hamano pisze: I personally think it is much more sellable to use an even simpler rule than what Jeff suggested, to make git push -- refspec go to the remote.pushdefault (falling back to remote.default that is origin), without even paying attention

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

2013-04-14 Thread Ramkumar Ramachandra
Junio C Hamano wrote: [...] In any case, dispelling a misplaced blame on matching is not the main point of this message. I _thought_ matching was a good scapegoat to blame current user expectations on. However, it's okay if you think that we're misplacing the blame. As long as we can agree

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

2013-04-14 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: ... In my proposal, the precedence order branch.name.pushremote, remote.pushdefault, branch.name.remote, remote.default, origin, remains the same: we just want to change which branch that name refers to. That changing the meaning of name in

[RFC/PATCH] push: introduce implicit push

2013-04-12 Thread Ramkumar Ramachandra
Currently, there is no way to invoke 'git push' without explicitly specifying the destination to push to as the first argument. When pushing several branches, this information is often available in branch.name.pushremote, falling back to branch.name.remote. So, we can use this information to

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

2013-04-12 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Currently, there is no way to invoke 'git push' without explicitly specifying the destination to push to as the first argument. When pushing several branches, this information is often available in branch.name.pushremote, falling back to

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

2013-04-12 Thread Ramkumar Ramachandra
Junio C Hamano wrote: The primary reason is the confusion factor Jeff mentioned in the thread that inspired this patch. People would realize it is very natural to decide where to push to based on what branch is being pushed, but only after they think it long and hard enough [*1*]. I suspect