Jonathan Nieder wrote: > My first hunch is not to like this, since it means > > git push -- master next > > might push to two different remotes and because it's not obvious > to me when it would be useful. Yes, it will push to two different remotes. And why is it not useful? If we also had something corresponding to branch.<name>.merge for push*, I would argue that this and branch.<name>.pushremote together define how a branch should be pushed, independent of everything else. Like I said earlier, I don't think of a git repository as a whole, but rather a collection of upstream and forked branches. Every branch is always fetched from its upstream (might or might not be the same as fork) using branch.<name>.remote, and pushed to its fork using branch.<name>.pushremote. A git push; can use the context of the current branch to select branches (along with their configurations) to push, nothing more. It should not apply the configuration of the current branch to the other branches that it's pushing; that's just wrong. * Can we write this branch.<name>.pushmap, effectively overriding branch.<name>.merge when in push.default = upstream and simple? -- 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