Junio C Hamano wrote:
> 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".

Okay, so it should _never_ push out as "triangle", because it is an
insane default.

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

I assumed that we want all push.default modes to do something
"sensible" in both central and triangular workflows.  push.default
dictating a push destination would break triangular workflows.  It's
very clear to me.

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

Okay, you've made your point.  Due to namespace conflict, the solution
I proposed is not at all a "sane" default.  It's just confusing and
Bad (TM).

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

Okay, we'll have to do some sort of split and mark push.default =
upstream/ simple suitable-only-for-centralized-workflows, or something
to that effect (deprecation?) :|

I'll try to think of something.
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