Ramkumar Ramachandra wrote:
> you'd essentially have to grab the remote..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 layer
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 i
Ramkumar Ramachandra 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 will al
On Thu, May 23, 2013 at 5:42 AM, Ramkumar Ramachandra
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 hardcode
>> t
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
> mome
Ramkumar Ramachandra writes:
> I suspect that the issue you're trying to address is:
>
> [remote "ram"]
> push = refs/heads/*:refs/heads/rr/*
>
> not dictating which refs to push when I say 'git push' (it'll push all
> the refs under refs/heads/*, not respecting push.default=current in my
> s
On Sun, May 19, 2013 at 6:54 AM, Ramkumar Ramachandra
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 possibly i
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
On Sun, May 19, 2013 at 6:44 AM, Ramkumar Ramachandra
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 problem: it is
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
push.def
Ramkumar Ramachandra 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..push. The only
>> problem I may have with the approach would arise _only_ if we make
>> it the sole way to allow people pus
On Sat, May 18, 2013 at 3:07 PM, Ramkumar Ramachandra
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 saying: if
On Sat, May 18, 2013 at 1:27 PM, Ramkumar Ramachandra
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..push. The only
>> problem I may have with the approach would arise _only_ if we make
>> it t
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
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
> peopl
Ramkumar Ramachandra 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 branch
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
> (, ))? Will we have a remote tracking branch for it
> to record what we pushed there the last time? I am guessing that
> your answers
Ramkumar Ramachandra 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 refer to
where the
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 presente
On Thu, May 16, 2013 at 8:59 PM, Felipe Contreras
wrote:
> On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Felipe Contreras writes:
>>>
What happens if I want to push to 'refs/heads/topics/frotz-for-juno'?
>>>
>>> You would weigh pros-and-cons of sup
On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Felipe Contreras 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 bran
Junio C Hamano writes:
> Felipe Contreras 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
> benefit outweighs the cost of com
On Thu, May 16, 2013 at 6:17 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano 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
>>> 'mast
Felipe Contreras writes:
> On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano 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 is a branch with a very generic
>>
On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano 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 is a branch with a very generic
> purpose (e.g. "to advance the stat
25 matches
Mail list logo
