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
I do agree that separating
- where to push to, and
- where to fetch for integrating with
is a necessary step for supporting triangular workflow better.
The "upstream" is that on top of which you build your work. You
clone from there to bootstrap yourself, you add your work (which may
include
26 matches
Mail list logo
