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