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

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>> The name under which the local branch is published needs a sensible
>> default (when branch.$name.push is not specified), and I agree that
>> you would get the name of the branch my work was forked from if you
>> reuse the "upstream" code.  I am saying that it does not necessarily
>> give us a good default.
>
> See, that's the problem: push.default is simply a default refspec to
> push to for all branches, that can be _overridden_ by
> branch.<name>.push.

Think again and remember that Git is distributed.

As you say, the push.default configuration specifies the mode that
computes what remote branches are updated.  Where we differ is that
I consider "triangle" branch at your repository I fetch from and
"triangle" branch at the repository I push to (in the triangular
workflow) different entities, just like "triangle" branch in my
local repository is different from both.  branch.triangle.merge
configuration is used to link the first and the third, and the first
is called "upstream" of the third for this reason.  It does not have
anything to do with the second.  You seem to think branch.*.merge is
used to link the second with the first, and I do not think it makes
any sense.

> Getting an override is not going to solve the
> problem we are facing: what to do when branch.<name>.push is
> unspecified?  Fall back to push.default, right?

That is not the issue.  We both are solving it by falling back to
push.default, but the problem is that the mental picture you have
for push.default has not been updated to support the triangular
world better.  In the centralized world, the first and the second
(in the above description) remote branches, both of which are named
"triangle", are the same, because they are in the same remote
repository.  Trying to reuse that in the triangular world is *not*
automatically being orthogonal and better; it may be simply keeping
things inconvenient by choosing a wrong definition, which is what I
am trying to avoid by thinking things through.

>> Now think _why_ I renamed the branch on my end, i.e. not calling
>> that branch in question "triangle" that is the blanket name for the
>> collective effort but calling it with a more specific name
>> "pushbranch", in the first place.
>
> Look, it's very simple.  upstream was built to support the case when
> the local branch name is different from the remote branch name, but it
> was too specialized for central workflows.  How do we extend it for
> triangular workflows?

"upstream" is for the case where you push back to your "upstream",
that which you fetch from and integrate with.  It is perfectly fine
to extend it for triangular workflow by erroring it out when it is
used, as you do *not* want to update "upstream" in that workflow.
You are sending your work to your publishing repository.

> Just like we introduced branch.<name>.pushremote to override
> branch.<name>.remote, we get branch.<name>.push to override
> branch.<name>.merge.  If branch.<name>.pushremote is unset, where do
> the pushes go?  branch.<name>.remote.  If branch.<name>.push is
> unspecified, what is the refspec to be pushed?  branch.<name>.merge
> (when push.default = upstream) [*1*].
>
> What does this mean?

Doesn't it just mean that you do not understand "distributed"?  

What makes you think that the repository you fetch from and the
repository you push to, which are by definition different
repositories, have to share the same namespace?

>  I publish the branch "triangle" on ram (what my
> local branch is called or what push.default I use is irrelevant).  You
> have a branch called pushremote with branch.pushremote.remote set to
> ram, remote.pushdefault set to junio, branch.pushremote.merge set to
> refs/heads/triangle, and push.default set to upstream.
>
>   # on jc's machine; on branch pushremote
>   $ git pull
>   # integrates changes from ram's triangle just fine
>   $ git push
>   # publishes the branch as triangle on remote junio

Only if I want to publish the result of the work forked from your
"triangle" as my "triangle", but that is not the case.  A fork to be
integrated by other is by definition more specialized than the
original, and I would publish my "pushbranch" subtopic as such, not
as "triangle".

It appears that the message you are responding to failed to convey
the primary point, so it may not be very useful for me to repeat it
here, but anyway.

> [Footnotes]
>
> *1* remote.pushdefault overrides branch.<name>.remote, while
> push.default will be overridden by a future branch.<name>.push.  Not
> exactly elegant, is it?

But that is not what is happening, unless you keep thinking
"push.default decides the name of the branch regardless of what
repository it lives in", which is where our difference lies, I
think.

Imagine the case where I forked two branches from your "triangle"
topic and pushing them to my repository using the triangular
workflow.  By your definition, they will both try to push to
"triangle", which means you, the "triangle" topic maintainer, cannot
receive two independent pull requests from me.  You can only get a
single branch that pre-merges both, and if you want to get one but
not the other, you have to do the untangling of these two topics.

The solution to the above becomes clear and simple, once you stop
thinking that the branch namespace you have has to be the same as
the branch namespaces other people have (which was limitation
imposed by central workflow, to which triangular has no reason to be
bound to).  Pushing to "upstream" by tying the name I fetch from and
the name I publish the result as is not appropriate in triangular
workflow, so just fail it.

I am not saying that you have to pick one to use for push.default
among the remaining ones (i.e. matching, current, what else?).  It
is very plausible that the triangular workflow wants a different
logic to pick what branches are to be updated and how.  Perhaps we
would want something that is capable of mapping your local branch
name to a branch name suitable in your publishing repository, and I
am not opposed to have such a mode.

But I think it _is_ a short-sighted mistake to consider "upstream"
the appropriate choice, if the reason to think so is only because
that is the only one that does any form of mapping in the current
system that was specifically designed to support workflow that
pushes back to where you fetched from to integrate with
(e.g. centralized).  We need to first ask if its mapping (i.e. what
the branch at "upstream" repository you merge into your local branch
in question is named) is the appropriate mapping to be used also for
pushing.  And I asked that question in the message you are
responding to (and my answer is it is not suitable).