Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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). -- 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