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
* 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html