On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote: > > Right, the example above might include multiple remotes if pushremote is > > respected. Or it might not come up with an answer at all for a tag. > > If you do: > > > > git push -- v1.2.3 master > > > > where does v1.2.3 go? To remote.pushdefault? That seems simple and > > consistent, as there is no ref-specific pushremote defined. > > remote.pushdefault indeed. > > > But I'd > > guess that the user probably _wanted_ it to go to > > branch.master.pushremote. > > Huh, why? Simply because he specified master alongside it? How can > we infer what you said in a consistent system? That's kind of my point. Why would they put two refs together in a single push command? Did they mean "I am pushing up master, and since I just tagged it, send the tag along, too"? Or did they really mean to push them to two different places? If so, why not just run two separate push commands? I am not saying git should guess that the user wanted the tag to along with master. I am saying that the set of rules to come to that conclusion is going to be too baroque for the user to understand, and too often wrong in other cases, and that we should not go there. -Peff -- 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