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..pushremote, falling back to branch..remote. So,
we can use this information to create a mor
Ramkumar Ramachandra 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..pushremote, falling back to branch..remote. So,
> we
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
> sus
Ramkumar Ramachandra writes:
> I agree with you largely, but I would still argue that choosing a
> destination based on the current branch is a historical mistake made
> by "matching".
"matching" is not necessarily a good default for everybody, and we
are fixing that historical mistake in Git 2.
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 --
>
> go to the remote.pushdefault (falling back to remote.default that is
> "origin"), without even paying attention
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 a
Ramkumar Ramachandra writes:
> ... In my proposal, the
> precedence order branch..pushremote, remote.pushdefault,
> branch..remote, remote.default, origin, remains the same: we
> just want to change which branch that refers to.
That "changing the meaning of " in the middle, and doing so
will b
Am 4/15/2013 5:04, schrieb Junio C Hamano:
> Ramkumar Ramachandra writes:
>
>> ... In my proposal, the
>> precedence order branch..pushremote, remote.pushdefault,
>> branch..remote, remote.default, origin, remains the same: we
>> just want to change which branch that refers to.
>
> That "chang
Johannes Sixt 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.
The user has be
On Mon, Apr 15, 2013 at 12:20:32AM -0700, Junio C Hamano wrote:
> Johannes Sixt 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
John Keeping wrote:
> 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
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.
>
>
Junio C Hamano wrote:
> That "changing the meaning of " 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..pushremote. In
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 alter
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..remote is what is used when I run "git push" with no
> > additional arguments.
> >
> > This is probably because whenever I add
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
On Mon, Apr 15, 2013 at 4:59 AM, John Keeping 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 think this d
On Mon, Apr 15, 2013 at 11:39:40AM -0500, Felipe Contreras wrote:
> On Mon, Apr 15, 2013 at 4:59 AM, John Keeping 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 confl
On Mon, Apr 15, 2013 at 12:13 PM, John Keeping 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 wrote:
>>
>> > So the question is "what is the natural extension of the current
>> > behaviour?", and the answer for me is "it
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> That "changing the meaning of " 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 maste
Jonathan Nieder wrote:
> As you hinted before, this would involve reverting the introduction
> of "branch..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 th
21 matches
Mail list logo
