Ramkumar Ramachandra <artag...@gmail.com> writes:

> Junio C Hamano wrote:
>>> They're not the same thing.  It is very much intentional and intended:
>>> the safety net is not to "ensure that the push and pull are
>>> symmetrical" (i.e. among other things, error out if
>>> branch.$branch.merge is unset), but rather "ensure that the push and
>>> pull are never asymmetrical".
>>
>>     not to "ensure that the push and pull are symmetrical"
>>     rather "ensure that the push and pull are never asymmetrical".
>>
>> They still talk the same thing to me.  What am I missing?
>
> Never mind the wording then.  I am proposing preventing asymmetry by
> explicitly disallowing a push when $branch is different from
> branch.$branch.merge, instead of shutting down immediately when
> branch.$branch.merge is unset.

We always said "upstream is to update the branch you fetch and
integrate with", and tried to make sure the push destination is the
branch you configured the current branch (i.e. the one you are
trying to push out) to fetch and integrate with.  That is how we
prevent asymmetry.

We fail if branch.$branch.merge is set to something else.  We also
fail if branch.$branch.merge is *not* set, because by definition the
branch you are trying to push to in that scenario cannot be the
branch you fetch and integrat with by "git pull [--rebase]".

I know your patch was attempting to change the behaviour for the
latter.  You are trying to let anything go if branch.*.merge is not
set.  How would it help prevent assymetry?

>>> Now I'd like to question what you are labelling as "safety".  What is
>>> the consequence of erroring out when branch.$branch.merge is unset
>>> when pushing using `upstream`?
>>
>> Nothing noteworthy.
>>
>> I wasn't suggesting to change what `upstream` does at all.
>
> No, but I did....

Really?  Then where did this come from?

> I didn't want to contaminate this series with an unrelated improvement
> to `upstream`

>> If you are using a
>> centralized workflow, and if a branch does not have branch.*.merge
>> configured, we do not know to which branch you are pushing it back,
>> so we error out.
>
> And I said: have a sane default.

Like you said, I do not want to contaminate this series with such an
unrelated change.  Worse, you are trying to break a sane default by
replacing it with "anything goes".

We already have a sane default, which is to error out.  We do not
need your broken default.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to