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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html