Re: Random thoughts on "upstream"

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 18, 2013, 18:27 UTC
Message-ID: <CALkWK0kYKZGhthdrb6-7RD_c2A7E9rscAZU3=JHM-4rYre6w=Q@mail.gmail.com>
In-Reply-To: <7vk3mxze8v.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

> Having said that I am not sure where your "not overly fond of" comes
> from, as I do not see a problem with branch.<name>.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.<name>.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.<name>.merge at all. That is why I'm tiling towards remote.<name>.push: we're not giving up any functionality anyway; there's nothing we can't do without branch.<name>.push.