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

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

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> 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.

That is where we differ.  You keep repeating that without justifying
why reusing the branch upstream would have chosen in a non-triangular
workflow is a good idea in the first place.

Let's step back a bit and think.  In a workflow where we both agree
that "upstream" mode makes sense, i.e. central repository workflow,
we may have a "triangle" topic in our shared repository, and I may
have my own topic forked from it (i.e. set to fetch that "triangle"
and integrate my work with it).  The topic is to work on one aspect
of triangular workflow, e.g. "pushbranch" (i.e. I am not worried
about how we choose which remote to push to, but interested in what
branch at that remote is updated).

It makes sense for me to push the result back to the upstream,
i.e. "triangle" branch at the shared remote where I forked from, to
collaborate with other people (e.g. you) whose shared purpose is to
improve the triangular workflow.  You may be doing the same, and
your local branch may be called "triangle" (bag of various
triangular workflow improvements), or "pushremote" (a specific
subtopic).  In either case, you push to "upstream" to update
"triangle".

What should happen in a triangular workflow, where I may be fetching
and integrating from your repository to work on triangular workflow
in general (let's say that you are the owner of that topic) to
advance the support for that workflow.  The topic in your repository
may be called "triangle" to improve triangular workflow in general,
and again my branch would be "pushbranch" to improve one specific
aspect of it.

As we are using triangular workflow, the place *I* push to is under
my control, not the shared maintainer one or your repository, and
I'll be requesting you to pull that topic from me.

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.

It is to clarify that my part of the effort is that particular
subarea of the topic.  Wouldn't it be a lot more sensible to use
that more specific name when publishing, rather than "triangle"
name, and ask you to pull that branch that describes what I
concentrated on?

Push destination and fetch source, when they are different, refer to
different repositories by definition, and they are in different
administration domains.  Why should the name used to publish my work
which is a specialization of what I built on (i.e. your "triangle")
lose the specialization from its name when I push it out?  We can
afford not to lose information in the branch name.

The difference between the shared repository case and triangular
workflow primarily comes from the fact that the final integration
happens at a different place.  In the shared repository case, the
integration happens in each participant's local repository and push
updates the shared history at the known name.  If my "pushbranch"
specialization diverted from the overall "triangle" effort, I would
first integrate others work and then update the remote, and at that
point, what I am pushing is no longer an isolated specialized effort,
but the result of its integration into a larger topic.

And once the more specialized topic is integrated into a more
generic branch it was forked from, it makes sense to update that
more generic branch at the shared repository.

In the triangular case, however, you as the "triangle" topic owner
has the choice to fetch and integrate from me or not to do so.  And
the integration happens when you decide to fetch and integrate.
There is no reason whatsoever to lose the more specific name until
that integration happens into your (meaning: the owner of the more
general "triangle" topic) "bag of various triangular improvements"
topic.

Imagine the case I forked two branches from your "triangle" topic
and pushing them to my publishing repository using the triangular
workflow.  Why should I attempt to update a single "triangle" branch
with both of these topics?

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.