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
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
> 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