Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Currently, there is no way to invoke 'git push' without explicitly > specifying the destination to push to as the first argument. When > pushing several branches, this information is often available in > branch.<name>.pushremote, falling back to branch.<name>.remote. So, > we can use this information to create a more pleasant push experience. > You can now do: > > $ git push master next pu > > If the branches master, next, and pu have different remotes, do_push() > will be executed three times on the three different remotes. I am lukewarm on this one, slightly more close to negative than positive, for a couple of reasons. The primary reason is the confusion factor Jeff mentioned in the thread that inspired this patch. People would realize it is very natural to decide where to push to based on what branch is being pushed, but only after they think it long and hard enough [*1*]. I suspect that it is an equally natural expectation for casual users that the destination is chosen based on the current branch, if only because that is what they are used to seeing when they say "git push" without any argument. Even though I personally am in favor of this "destination is tied to what is pushed out", not "destination is chosen based on the current branch", I can understand why some people would prefer the latter, and why they find it simpler and easier to explain. The second reason is purely on the differences between what the above clean-nice explanation says and what the patch actually does. I think "is-possible-refspec" and "pushremote-get-for-refspec" are both way over-engineered, even for people who agree with me and the above introduction for this change to favor "destination depends on what branch is pushed out". If is-possible-refspec is replaced with a much simpler to understand logic, "Is this a local branch name?", possibly combined with "There is no such path on the filesystem" and "It's not a defined remote" (iow, reject "git push master:next" and anything more complex) [*2*], I suspect it would be a bit more sellable. [Footnote] *1* I've explained in a separate message why basing the destination on what is being pushed is logical and internally consistent. *2* This is in the same spirit (not implementation or design) as revname vs pathspec disambiguation. -- 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