Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
> 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.
-ECANTSEEWHATYOUMEAN. Your proofreader is 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 thought branch.$name.push is "What ref do I push this out as?"
At this point you have two remotes, me as your upstream, and your
publishing point, and remote.pushdefault set to the latter since
originally you cannot push to 'origin':
[push]
default = simple ;# adopt 2.0 default early
[remote]
pushdefault = ram
[remote "ram"}
url = github.com:ram/something.git
fetch = +refs/heads/*:refs/remotes/ram/*
push = +refs/heads/*:refs/heads/*
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
# assuming you forked from my master
[branch "hot-branch"]
remote = origin
merge = refs/heads/master
+ pushremote = origin
+ push = refs/heads/rr/hot-branch
The above pseudo-diff would be the changes you would be making to
your configuration when you were asked to push your 'hot-branch' to
'origin' as 'rr/hot-branch', I think.
If somebody implements the "push.default = single" (see the original
message you are responding to), then the change might be smaller.
[push]
- default = simple ;# adopt 2.0 default early
+ default = single
[remote]
pushdefault = ram
[remote "ram"}
url = github.com:ram/something.git
fetch = +refs/heads/*:refs/remotes/ram/*
push = +refs/heads/*:refs/heads/*
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
+ push = +refs/heads/*:refs/heads/rr/*
# assuming you forked from my master
[branch "hot-branch"]
remote = origin
merge = refs/heads/master
+ pushremote = origin
> 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.
Somewhat true, if you write this with branch.hot-branch.push without
push.default=single implicitly introduces
refs/heads/hot-branch:refs/heads/rr/hot-branch
refspec to the remote named by branch.hot-branch.pushremote.
--
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