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.<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.
--
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