From: Ramkumar Ramachandra Date: Mon, 15 Apr 2013 09:35:17 GMT Subject: Re: [RFC/PATCH] push: introduce implicit push Message-ID: In-Reply-To: <7vppxw335o.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > That "changing the meaning of " 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..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..pushremote, and it's not a problem in my opinion. After all, a git fetch also considers branch..remote, and we all agree that this is fine. 1. We are changing the meaning of branch..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..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.