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
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.
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
