Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > I suspect that the issue you're trying to address is: > > [remote "ram"] > push = refs/heads/*:refs/heads/rr/* > > not dictating which refs to push when I say 'git push' (it'll push all > the refs under refs/heads/*, not respecting push.default=current in my > scheme). That is not what I was addressing. You outlined your scenario as "you were not, but you are now, allowed to push an approved ref into 'origin'". And you do so under a different name. That is why I set that rr/ renaming push refspec for a remote ORIGIN not RAM. And that was done with extensivility your example implied in mind: you may later be allowed to push other branches as well to origin. That is why the refspec definition for 'origin' does not hardcode the name of the branch you are permitted to push there at this moment. The fact that hot-branch goes to origin is encapsulated in the branch.hot-branch.pushremote. The rule, under which the name of any branch that goes to the origin is renamed, is encapsulated in remote.origin.push refspec (the introduction of the new mode "push.default = single" is necessary to make this work). When making that change, our fictitious ram did not have to touch "remote.ram.push" *at all*. Independent of what the owner of "origin" and ram agreed in that example, ram would keep doing exactly the same thing to his own publishing point so that people who are working off of his work would get updates from the place known to contain his work from before. So with "git push ram", it will push everything to "ram" under the same name *without* rr/ renaming, but that was *by design*, not something I wanted to or I needded to work around. And you would also push to "origin" by doing "git push" while on hot-topic branch. -- 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