From: Ramkumar Ramachandra Date: Sat, 18 May 2013 18:27:41 GMT Subject: Re: Random thoughts on "upstream" Message-ID: In-Reply-To: <7vk3mxze8v.fsf@alter.siamese.dyndns.org> Junio C Hamano wrote: > Having said that I am not sure where your "not overly fond of" comes > from, as I do not see a problem with branch..push. The only > problem I may have with the approach would arise _only_ if we make > it the sole way to allow people push to different names, forcing > people who want to push N branches to configure it N times. Other > than that, I think it is an acceptable solution to give per-branch > control. It doesn't strike me as being elegant at all. [branch "hot-branch"] remote = ram push = refs/heads/for-junio/hot-branch 1. I git branch -M for-each-ref and push. Screwed. 2. Let's say you give me the thumbs up to write hot-branch to origin. Excitedly, I change the remote to origin. Now I already have push semantics for origin (you obviously want me to write to rr/, so I can cooperate with others): [remote "origin"] push = refs/heads/*:refs/heads/rr/* Unfortunately, it doesn't kick in unless I change branch..push. I guess what I'm saying is: refspec semantics are inherent properties of the remote, not of the local branch. Since there is no intermediate refs/remotes/* sitting between the remote and local branches, this is _not_ like branch..merge at all. That is why I'm tiling towards remote..push: we're not giving up any functionality anyway; there's nothing we can't do without branch..push.