Re: Random thoughts on upstream
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 layer.
(@{push} is already in progress; see list)
2. Forcing the transport layer to ignore remote-push and use the fed
refspec instead. (I'm not sure how to do this yet)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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. The fact that hot-branch goes to origin is encapsulated in the branch.hot-branch.pushremote. The rule, under which the name of any branch that goes to the origin is renamed, is encapsulated in remote.origin.push refspec (the introduction of the new mode push.default = single is necessary to make this work). My problem with this entire scheme _is_ the magic push.default = single. Currently, push.default only kicks in when no remote.name.push refspec is specified (in other words, it is a default value of remote.name.push for all remotes), and I don't think we should change this. If the user wants to configure the push refspec (either for rewriting, or for determining what to push), there is exactly one thing to change: remote.name.push. So I can have: [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 always push all branches without force with rewriting, irrespective of the branch I'm on. [remote ram] push = HEAD:refs/heads/rr/%1 This means that I will always push the current branch without force, with rewriting. [remote felipe] # empty This means that remote.felipe.push falls back to the refspec specified by push.default. Isn't branch.name.push is completely unnecessary? Does this make sense to you? Isn't it more straightforward and general (how do I get a push.default = single on a per-remote basis) than your solution? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 hardcode
the name of the branch you are permitted to push there at this
moment. The fact that hot-branch goes to origin is encapsulated in
the branch.hot-branch.pushremote. The rule, under which the name of
any branch that goes to the origin is renamed, is encapsulated in
remote.origin.push refspec (the introduction of the new mode
push.default = single is necessary to make this work).
My problem with this entire scheme _is_ the magic push.default =
single. Currently, push.default only kicks in when no
remote.name.push refspec is specified (in other words, it is a
default value of remote.name.push for all remotes), and I don't
think we should change this. If the user wants to configure the push
refspec (either for rewriting, or for determining what to push), there
is exactly one thing to change: remote.name.push. So I can have:
[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 always push all branches without force with
rewriting, irrespective of the branch I'm on.
[remote ram]
push = HEAD:refs/heads/rr/%1
This means that I will always push the current branch without force,
with rewriting.
[remote felipe]
# empty
This means that remote.felipe.push falls back to the refspec
specified by push.default.
Isn't branch.name.push is completely unnecessary?
No, it's not; 'git push --set-downstream' is not going to configure
that for the user. Nor will the user be able to see the downstream
with 'git branch -vv', nor will the user be able to see the downstream
with 'git rev-parse branch@{downstream}'.
You keep ignoring those use-cases I already mentioned multiple times
because they don't fit your idealistic model.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 will always push all branches without force with rewriting, irrespective of the branch I'm on. Exactly. And some people are unhappy about it, because they prefer to work per-branch basis, as opposed to having to perfect everything into a publishable state first and then finally push everything out in one go. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 has, in my opinion, is ease of implementation: 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. Compare that to inventing a new refspec syntax, which is a mammoth task. We can always extend the refspec later, if we want that. I wonder if it makes sense to bake the functionality into current though: will we be breaking anything? (My opinion has changed after wrestling with the horrible transport layer) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 possibly introducing more sore thumbs like this in the future). Yeah, go ahead and have fun making refspecs Turing complete. Why? Because you decided to call something a sore thumb. Calling something a sore thumb doesn't make it so. We, the sane people, will people will keep using simple configuration options. Hopefully some day there won't be much need for many of the current configurations, including push.default. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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.default as merely a default remote.name.push value for all remotes, that can be overridden on a per-remote basis. 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 scheme). That is a valid problem, and it is a problem with our refspec: I can say HEAD (which is what push.default=current is) to mean current branch, but I can't dictate the rhs of the refspec then. In other words, I cannot have the refspec HEAD:refs/heads/rr/%1, and _this_ is the problem. What do you think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 problem: it is ugly, confusing, and inextensible in my opinion. I think of push.default as merely a default remote.name.push value for all remotes, that can be overridden on a per-remote basis. You can't represent push.default = single either. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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. 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 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. That is why I'm tiling towards remote.name.push: we're not giving up any functionality anyway; there's nothing we can't do without branch.name.push. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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] push = refs/heads/for-junio/link is saying: push _this_ branch to for-junio/link, irrespective of what it is called. An example illustrating this clearly: # on branch link-v2 # work ... $ git push # work ... # ok, I'm ready to replace link $ git branch -M link $ git push # where should the push go? Also: putting branch-specific configuration in remote.name.push would mean that it can potentially accumulate a lot of cruft from deleted branches. It's the same kind problem we face with .gitignore, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 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
s/remote/pushremote/
1. I git branch -M for-each-ref and push. Screwed.
Can't parse that.
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.
If course it doesn't that's what you told git to do. Of course, you
could simply do:
% git branch --set-downstream-to origin/rr/for-junio/hot-branch
Or if you are going to push multiple branches and set a 'remote.name.push':
% git branch --unset-downstream
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. That is why
I'm tiling towards remote.name.push: we're not giving up any
functionality anyway; there's nothing we can't do without
branch.name.push.
Yes there is, I thought you already acknowledged that:
% git branch --set-downstream-to github/fc/master
% git rebase -i @{downstream}
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 saying: if the branch name matches link, push it to for-junio/link. [branch link] push = refs/heads/for-junio/link is saying: push _this_ branch to for-junio/link, irrespective of what it is called. An example illustrating this clearly: # on branch link-v2 # work ... $ git push # work ... # ok, I'm ready to replace link $ git branch -M link $ git push # where should the push go? Exactly where you told it to go. Also: putting branch-specific configuration in remote.name.push would mean that it can potentially accumulate a lot of cruft from deleted branches. It's the same kind problem we face with .gitignore, no? Not many people would use 'remote.name.push' and in very specific circumstances. It's not a problem. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 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. Think of what
remote.name.push and branch.name.push are actually going to be
used for:
remote.name.push are most probably going to be used with wildcards
(like in the Gerrit case): I don't mind if @{f} is not able to tell me
where my branch will go (and it's probably even a pseudo-ref, in which
case the answer is really meaningless). The limitation doesn't affect
remote.name.fetch, because @{u} only operates between remote
branches and local branches, not at the ref-mapping level.
branch.name.push cannot be used with wildcards, and @{f} is pretty
straightforward to determine in this case. When the information is
easily available for end-user consumption, why would we _not_ want to
expose it by stuffing branch.name.push into remote.name.push
configuration?
So, I think the way forward is:
1. Introduce @{f[ork]} to show $(branch.name.pushremote or
remote.pushdefault)/$(HEAD). We can update 'git status' to show this
information as well: the ahead/ behind with @{f} is no less important.
2. (optional) Make remote.name.fetch non-mandatory. Currently, a
lot of git-core breaks unless this is present, and this is an annoying
wart.
3. Introduce remote.name.push. Make it clear that it is intended
for the Gerrit-user. @{f} cannot be determined with this [*1*].
4. Introduce branch.name.push for a branch-specific override to
remote.name.push. @{f} can be determined when this is in effect.
[Footnotes]
*1* Do we want to do some magic wildcard-expansion to get/set @{f}
anyway? In which case, branch.name.push is really not necessary.
Which approach is less ugly?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 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 answers to both of these questions are Yes, and frotz@{f}
would resolve to refs/remotes/there/topics/frotz-for-juno in the
sample set-up in the message you are responding to.
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 to, and other people would
consider it my fork of the upstream project, but it is hard
to do the reverse, i.e. a new person who is presented a word
'fork' to guess that you wanted to refer to the above by
that word.
I am not saying branch.name.push should not exist. Having a
finest-grained special case would be an escape hatch you can use
when you want to do something unusual.
But it has exactly the same issue as branch.name.pushremote;
adding it without having the single all of my pushes go to here,
not to 'origin' would have meant that for N branches you have to
set the same thing N times. We fixed it with remote.pushdefault
before the series graduated. If you only add branch.name.push,
then people have to configure it N times, for N branches they want
to push out.
Reusing the existing push refspecs was just a suggestion to solve
that issue, and I am not married to that particular design. You or
Felipe may be able to come up with a better alternative to achieve
the same goal and that is perfectly fine. I just wanted to make
sure that we do not force the user to repeatedly set the same thing
over and over in the common case.
By the way, about crippling.
I do not think of a reason why you cannot implement that @{f} with
the 'single' matching (or its better version you may come up with).
If git push can figure out where it would push to, you certainly
should be able to borrow that same logic to see what tracking branch
you are locally using to track the last push result for the current
branch in response to @{f} request, no?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 answers to both of these questions are Yes, and frotz@{f}
would resolve to refs/remotes/there/topics/frotz-for-juno in the
sample set-up in the message you are responding to.
Yes.
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 to, and other people would
consider it my fork of the upstream project, but it is hard
to do the reverse, i.e. a new person who is presented a word
'fork' to guess that you wanted to refer to the above by
that word.
GitHub is an overwhelmingly popular service, and many end-users are
used to clicking on the Fork button on various projects to
contribute. Here, fork is short for my fork. Do you have a
better name in mind?
But it has exactly the same issue as branch.name.pushremote;
adding it without having the single all of my pushes go to here,
not to 'origin' would have meant that for N branches you have to
set the same thing N times. We fixed it with remote.pushdefault
before the series graduated. If you only add branch.name.push,
then people have to configure it N times, for N branches they want
to push out.
Oh, I'm completely against just adding branch.name.push as I've
pointed out on the other thread. Even in the part you clipped out, I
clearly stated remote.name.push above a branch-specific thing in the
priorities.
Reusing the existing push refspecs was just a suggestion to solve
that issue, and I am not married to that particular design. You or
Felipe may be able to come up with a better alternative to achieve
the same goal and that is perfectly fine. I just wanted to make
sure that we do not force the user to repeatedly set the same thing
over and over in the common case.
Ofcourse.
I do not think of a reason why you cannot implement that @{f} with
the 'single' matching (or its better version you may come up with).
If git push can figure out where it would push to, you certainly
should be able to borrow that same logic to see what tracking branch
you are locally using to track the last push result for the current
branch in response to @{f} request, no?
Ofcourse, I'm not saying it's not possible.
1. Getting @{f} requires extra computation, and that might be ugly/
undesirable/ surprising considering how @{u} doesn't require it.
2. Setting @{f} with branch --set-fork-to won't operate on the
branch.name section, and this might be surprising.
3. If remote.name.push is only going to be used by the Gerrit
people, @{f} is not going to work anyway.
These issues aren't deal breakers, but are certainly worth mentioning.
Frankly, I'm not overtly fond of the branch.name.push idea, and am
tilting towards this now. What do you think?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 is a branch with a very generic purpose (e.g. to advance the state of the overall project), but your work may have a more specific purpose (e.g. to improve frotz feature) that deserves to be on a branch named after that specific purpose in the repository you publish your work on. That is, after working on your 'frotz' branch this way: git checkout -t -b frotz origin/master work work work, commit commit commit If the user has branch.autosetupmerge=always, that's not correct; even doing: % git checkout -b frotz origin/master Would setup the upstream. And I believe for v2.0 we do want branch.autosetupmerge=always, but we might not want to always override the push location. Now I have a curious value single in the above configuration that is not understood by current Git. It is to trigger a new rule to modify the way remote.publish.push refspec is used: When on branch 'frotz', where pushremote_get() would return 'publish', find where refs/heads/frotz would be pushed with the refspec for that remote (i.e. refs/heads/*:refs/heads/topics/* maps refs/heads/frotz to refs/heads/topics/frotz) and push only that, i.e. update refs/heads/topics/frotz over there with the tip of 'frotz' we are pushing. That may be a solution for those who do not find 'current' good enough. 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 complexity, design and implement it. The push.default setting is to make sure we have a simple mechanism to cover more common cases, and my suspicion is what 'current' gives us is already there without the need for 'single'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 benefit outweighs the cost of complexity, design and implement it. The push.default setting is to make sure we have a simple mechanism to cover more common cases, and my suspicion is what 'current' gives us is already there without the need for 'single'. 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: [remote there] url = ... were you push ... push = refs/heads/frotz:refs/heads/topics/frotz-for-juno push = refs/heads/*:refs/heads/topics/* Without the 'single', your 'frotz' will be pushed to update heads/topics/frotz-for-juno, not heads/topics/frotz, because the exact refspec match will prevent it from matched twice by the wildcarded one. The imagined 'single' mode would just limit the push to the current branch, so it would end up pushing to the branch you want to update, without sending an extra copy to the same name. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 single branch only special case, and add a branch level override, and if the benefit outweighs the cost of complexity, design and implement it. The push.default setting is to make sure we have a simple mechanism to cover more common cases, and my suspicion is what 'current' gives us is already there without the need for 'single'. 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: [remote there] url = ... were you push ... push = refs/heads/frotz:refs/heads/topics/frotz-for-juno push = refs/heads/*:refs/heads/topics/* Without the 'single', your 'frotz' will be pushed to update heads/topics/frotz-for-juno, not heads/topics/frotz, because the exact refspec match will prevent it from matched twice by the wildcarded one. The imagined 'single' mode would just limit the push to the current branch, so it would end up pushing to the branch you want to update, without sending an extra copy to the same name. And would 'git branch --set-downstream-to github/frotz-for-juno' do that? If not it's basically useless for 99% of the users who never fiddle with push refspecs. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Random thoughts on upstream
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 '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 complexity, design and implement it.
The push.default setting is to make sure we have a simple mechanism
to cover more common cases, and my suspicion is what 'current' gives
us is already there without the need for 'single'.
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:
[remote there]
url = ... were you push ...
push = refs/heads/frotz:refs/heads/topics/frotz-for-juno
push = refs/heads/*:refs/heads/topics/*
Without the 'single', your 'frotz' will be pushed to update
heads/topics/frotz-for-juno, not heads/topics/frotz, because the
exact refspec match will prevent it from matched twice by the
wildcarded one. The imagined 'single' mode would just limit the
push to the current branch, so it would end up pushing to the branch
you want to update, without sending an extra copy to the same name.
And would 'git branch --set-downstream-to github/frotz-for-juno' do
that? If not it's basically useless for 99% of the users who never
fiddle with push refspecs.
And 'git branch -vv' would not show that either. Nor can the user do
'@{downstream}'.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
