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.

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

Reply via email to