On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote: > >> > If branch.$name.remote is "when I am on this branch, I want to talk to > >> > this remote", that rule is not be impacted by the presence of refspecs > >> > at all. > >> > >> So running the above while on 'maint' will send master and next to > >> the remote your "git push" would send to when run without any > >> refspecs? > > > > Exactly. The remote selection is orthogonal to the refspecs provided, > > and only cares about which branch you are on. > > > > Which is still kind of weird, because why should the branch you are on > > affect the default push location? But that is how default "matching" has > > always behaved, and we would remain consistent with that. > > git push -- master next; pushes to my current branch's > branch.<name>.pushremote? Isn't that a disaster? Maybe. But no more so than the current: git push which may also push master and next to the same remote. As I said in an earlier message, I would be OK with allowing both or neither, but allowing one but not the other is even more confusing. If we changed push.default=matching to ignore branch.*.remote, then that would be consistent, and would probably be safer over all. It is a regression, but I doubt that anybody was using branch.*.remote for this; it really only makes sense with the "upstream" mode. -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