Re: Random thoughts on upstream

2013-05-24 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: you'd essentially have to grab the remote.name.push refspec, rewrite it to replace refs/heads/*: with $HEAD: and feed that refspec to the transport layer Um, sorry. It involves two independent steps: 1. add_refspec() $HEAD:$HEAD@{push} to feed to the transport

Re: Random thoughts on upstream

2013-05-23 Thread Ramkumar Ramachandra
Junio C Hamano wrote: 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.

Re: Random thoughts on upstream

2013-05-23 Thread Felipe Contreras
On Thu, May 23, 2013 at 5:42 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: 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

Re: Random thoughts on upstream

2013-05-23 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: [remote theodore] push = master push = +pu This means that I will always push master without force and pu with force, irrespective of the branch I'm on. [remote origin] push = refs/heads/*:refs/heads/rr/* This means that I

Re: Random thoughts on upstream

2013-05-23 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I am not saying default=single would be _the_ single right way to solve it, but when you have default=single, remote.$name.push is used only to describe the mapping, not forcing you to push everything out at once is one possible solution to that. The big advantage it

Re: Random thoughts on upstream

2013-05-19 Thread Felipe Contreras
On Sun, May 19, 2013 at 6:54 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Felipe Contreras wrote: You can't represent push.default = single either. Right. And I propose that we extend the refspec to be able to represent it, instead of having single sticking out like a sore thumb (and

Re: Random thoughts on upstream

2013-05-19 Thread Ramkumar Ramachandra
Junio C Hamano wrote: If somebody implements the push.default = single (see the original message you are responding to), then the change might be smaller. I think this is a bad hack covering up an underlying problem: it is ugly, confusing, and inextensible in my opinion. I think of

Re: Random thoughts on upstream

2013-05-19 Thread Felipe Contreras
On Sun, May 19, 2013 at 6:44 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: If somebody implements the push.default = single (see the original message you are responding to), then the change might be smaller. I think this is a bad hack covering up an underlying

Re: Random thoughts on upstream

2013-05-19 Thread Ramkumar Ramachandra
Felipe Contreras wrote: You can't represent push.default = single either. Right. And I propose that we extend the refspec to be able to represent it, instead of having single sticking out like a sore thumb (and possibly introducing more sore thumbs like this in the future). -- To unsubscribe

Re: Random thoughts on upstream

2013-05-18 Thread Ramkumar Ramachandra
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

Re: Random thoughts on upstream

2013-05-18 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: I guess what I'm saying is: refspec semantics are inherent properties of the remote, not of the local branch. [remote ram] push = refs/heads/link:refs/heads/for-junio/link is saying: if the branch name matches link, push it to for-junio/link. [branch link]

Re: Random thoughts on upstream

2013-05-18 Thread Felipe Contreras
On Sat, May 18, 2013 at 1:27 PM, Ramkumar Ramachandra artag...@gmail.com wrote: 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

Re: Random thoughts on upstream

2013-05-18 Thread Felipe Contreras
On Sat, May 18, 2013 at 3:07 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Ramkumar Ramachandra wrote: I guess what I'm saying is: refspec semantics are inherent properties of the remote, not of the local branch. [remote ram] push = refs/heads/link:refs/heads/for-junio/link is

Re: Random thoughts on upstream

2013-05-18 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com 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

Re: Random thoughts on upstream

2013-05-17 Thread Ramkumar Ramachandra
Junio C Hamano wrote: Actually, I suspect that you shouldn't even need to do that pros-and-cons analysis, because the 'single' thing should cover as a natural extension of the existing infrastructure. You should only need to have something like this: Which is the exact argument I presented

Re: Random thoughts on upstream

2013-05-17 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Which is the exact argument I presented on the other thread. However, Felipe has a point: we shouldn't cripple @{f} (I think fork is a good name for it) in the name of generality. Please clarify the semantics of @{f}. Does it conceptually

Re: Random thoughts on upstream

2013-05-17 Thread Ramkumar Ramachandra
Junio C Hamano wrote: Please clarify the semantics of @{f}. Does it conceptually refer to where the current branch is going to be pushed to (i.e. a pair of (remote, ref))? Will we have a remote tracking branch for it to record what we pushed there the last time? I am guessing that your

Re: Random thoughts on upstream

2013-05-17 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: Side note: I do not think fork rings bell to the end users. Who is forking from what? I am guessing you are trying to make a short form of the branch in my public pepository I push this

Re: Random thoughts on upstream

2013-05-16 Thread Junio C Hamano
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano gits...@pobox.com wrote: The value upstream for push.default does not make sense in the context of a triangular workflow, as you may well base your work on 'master' from the upstream, which

Re: Random thoughts on upstream

2013-05-16 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: What happens if I want to push to 'refs/heads/topics/frotz-for-juno'? You would weigh pros-and-cons of supporting such a single branch only special case, and add a branch level override, and if the

Re: Random thoughts on upstream

2013-05-16 Thread Felipe Contreras
On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: What happens if I want to push to 'refs/heads/topics/frotz-for-juno'? You would weigh pros-and-cons of supporting such a

Re: Random thoughts on upstream

2013-05-16 Thread Felipe Contreras
On Thu, May 16, 2013 at 8:59 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: What happens if I want to push to