Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Junio C Hamano wrote: > >> [...] > > Okay, so what you're saying makes sense. That is not a very useful style of quoting; what did you just agree to? I think we should step back and clarify the "to which repository the push goes" and "what branch(es) in that chosen repository is updated". The former is determined by your original "triangular" topic in the recent world order. The push.default specifies the logic/algorithm to decide the latter, when there is no stronger configuration is given (e.g. the push refspecs in remote.*.push, and branch.*.push). > - current: push "$(HEAD)". No restrictions on destination. This updates the branch with the same name the current branch on the pushing side. > - matching: push ":" to the destination specified by the current > branch. This updates the branches in the destination repository, for which branches with the same name exists on the pushing side. > - upstream: In the special case when fetch source is equal to push > destination, push "$(HEAD):$(branch.$(HEAD).merge)". Otherwise, > fallback to current. Useful in central workflows. That looks to me as an inconsistent description. If you are not pushing to where you fetched from, that is not even central. This is mean to update the branch that is fetched from and is integrated with the current branch with the tip of the current branch, so the branch at the destination repository that gets updated is branch.$current.merge. It further means that the repository being pushed to must be the same as the repository we fetch from; otherwise it is an error. > - simple: [still haven't thought about what to do with this; I'm > generally not in favor of artificially crippling functionality by > erroring out] In a central workflow (i.e. repository we fetch from to update the current branch is the same as the repository we push the tip of this branch to), this works the same as upstream, but the configured branch.$current.merge has to be the same as the name of the current branch in the local repository; otherwise it is an error. In a triangular workflow TBD, but I think doing the same as current may be a good starting point. > Just like upstream respects branch.<name>.merge, current respects > branch.<name>.push, making branch-level ref mapping in triangular > workflows possible. I do not know we want to make branch.*.push linked to current. If it is set, shouldn't that apply when push.default is "matching" and other values? That is why I threw it in the same category as the traditional push refspecs in remote.*.push in the early part of this message. -- 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