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. 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? > 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? 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? 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 I rewrite my branch, and you have 4 commits based on my branch: $ git rebase --onto @{u} @~4 Perfect. The only limitation is that you don't choose the branch name on junio. When we get branch.pushremote.push, you'll be able to set it to refs/heads/pushremote, making push.default inconsequential. Done. [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? -- 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