Junio C Hamano wrote: > That "changing the meaning of <name>" in the middle, and doing so > will be confusing to the users, is exactly the issue, isn't it?
Yes, but we have to change _something_ if we don't want to hit a WTF like 'git push master next' pushing master and next to branch.<HEAD>.pushremote. In my opinion, this seems to be the less evil (or disruptive) change. After all, we're not proposing to change the current behavior of any current git invocations: a plain git push can still consider branch.<HEAD>.pushremote, and it's not a problem in my opinion. After all, a git fetch also considers branch.<HEAD>.remote, and we all agree that this is fine. 1. We are changing the meaning of branch.<name>.remote, but this is not inconsistent with the current behavior of push.default at all (even push.default=matching). We just have to improve the push.default documentation. 2. We are not changing the meaning of _any_ existing git push invocations. Pushing "unrelated branches" to the "corresponding remote" has not been possible until now (unless you check out each of the branches, set push.default=current, and git push), and we're inventing a new syntax that makes this possible. I see no problem with changing the meaning of branch.<name>.remote/pushremote for this purpose. > Just like Peff, I am sympathetic to people who want to omit "where > to" and have Git automatically make a guess, and would be happy if > we can find a reasonable solution to that problem. > > But I am not convinced what we discussed in these threads are good > solutions. At least not yet. There are only so many possibilities, Junio*. You either decide that the logical alternative that I proposed is too confusing and drop the idea, or think about how to move forward minimizing friction. * If you think there are other possibilities, I'd be glad to hear them. -- 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
