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?
>> 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).
Otherwise, I think we're consistent. git push master; pushes the
refspec master (with no explicit :<dst> counterpart) to the "default
place to push to" (either depending on which branch I am, or global).
I think Junio was mixing up refspecs with refs (branches, and hence
branch configuration) earlier. git push origin; pushes to "default
refspecs" on the remote origin. By extension, git push; should push
"default respecs" to the "default place to push to". The "default
refspecs" in this context is determined by push.default, which is the
problem.
--
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