Re: [PATCH 2/4] push: make upstream, simple work with pushdefault

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 10, 2013, 08:43 UTC
Message-ID: <CALkWK0mesZay8Cpi6yTvhUG=136=9JLyFUZXm8t_fMOrY0F62Q@mail.gmail.com>
In-Reply-To: <7vip1moq3k.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> I am not sure what you mean by artificial.

By artificial, I mean that the precondition is absolutely unnecessary for the code following it to work. The precondition was introduced in a separate commit, specifically denying one usecase because the author (you) thought that made sense.

Show 5 quoted lines

> If you have push.default set upstream or simple, then a push run
> while on the branch 'foo' will figure out what happens when you do a
> fetch by looking at 'branch.foo.merge' to find the branch we are set
> to integrate from 'branch.foo.remote' remote.  The simple further
> says that branch name must be the same as 'foo'.

I understand this perfectly well, as evidenced by the tests I've written out in 4/4.

Show 7 quoted lines

> And that is what setup_push_UPSTREAM() is designed to do.  Rejecting
> a call that breaks the precondition is perfectly the right thing to
> do: if you set to push to "upstream" and if you are trying to push
> to a different remote, for example.
>
> The triangle topic changed the precondition without updating the
> logic to check it, which was the bug, not the original check.

Did I claim otherwise? :) The topic is about fixing a bug introduced by rr/triangle.

> I actually am OK with 'upstream' that rejects triangular, while
> making 'simple' do something different [*1*].

Okay, so you haven't outlined a solution either. Like I said in the cover-letter, I've spent hours breaking my head and can't figure out a better solution. The bigger problem is that upstream/ simple were designed with only central workflows in mind. How do we deal with it now?

Yes, upstream/ simple work only when @{u} resolves, and I haven't changed this (because we don't have a well-defined meaning for what branch.<name>.merge without a branch.<name>.remote means). My argument is very simple: no push.default mode should not dictate the push destination; only the push refspec. What makes sense to the user is an upstream/ simple that works as expected with pushdefault: do the tests I've outlined in 4/4 not make sense? *scratches head*

I don't understand why upstream/ simple should _not_ push to a different destination from the one being merged from. I'll repeat: push source/ destination is orthogonal to push refspec, and push.default modes dictate the refspec.