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.
> That is internally consistent and understandable, and I have no
> objection to it. Certainly much better than basing the decision on
> branch.{master,next}.remote as I thought you were suggesting to do.
No, I am not suggesting that. I can see how such a command might be
useful (i.e. "push master to where it goes, next to where it goes",
where "goes" is defined by the upstream config). But that is not
remotely close to how "git push" works now, and would be inconsistent
with the other modes (e.g., matching, explicit refspecs, pushing
non-branches, etc).
-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