Junio C Hamano wrote:
> When pushing into other kinds of repositories (e.g. you can update
> some but not all of the branches, or you want to touch only some of
> them and not others even if you have enough privilege to update any
> of them) or when you do not "batch" and push out one branch as wor
Jeff King writes:
> Which is still kind of weird, because why should the branch you are on
> affect the default push location? But that is how default "matching" has
> always behaved, and we would remain consistent with that.
I agree that what makes us behave "kind of weird" is that the
current
Ramkumar Ramachandra writes:
> Let us imagine that origin points to git/git.git (upstream), ram
> points to artagnon/git.git and peff points to peff/git.git. I fork
> off from upstream and have various local branches that only have
> corresponding refs in ram (say implicit-push). Then, you fork
Ramkumar Ramachandra wrote:
> - branch.implicit-push-next.pushremote set to null**, because I will
> never want to push this branch.
Currently, I have a hacky workaround: I set
branch.implicit-push-next.pushremote to a remote that I don't have
write access to (ie. origin), effectively failing all
Jeff King wrote:
> $ git clone https://github.com/upstream/project.git
> $ cd project
> $ hack hack hack; commit commit commit
> $ git tag -m 'something of note' my-tag
> $ git remote add me https://github.com/me/project.git
> $ git config branch.master.remote me
> $ git tag -m 'somet
Jeff King wrote:
> To flesh out my earlier example:
>
> $ git clone https://github.com/upstream/project.git
> $ cd project
> $ hack hack hack; commit commit commit
> $ git tag -m 'something of note' my-tag
> $ git remote add me https://github.com/me/project.git
> $ git config branch.mas
On Thu, Apr 11, 2013 at 03:41:33AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > It's not that it's not potentially useful. It's that it may be
> > surprising and annoying to users who did not want that.
>
> Besides, I'm not able to imagine one scenario where this is the wrong
> or an
On Thu, Apr 11, 2013 at 03:36:10AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > It's not that it's not potentially useful. It's that it may be
> > surprising and annoying to users who did not want that.
>
> ... but this is a new syntax, and doesn't break any existing
> expectations.
Jeff King wrote:
> It's not that it's not potentially useful. It's that it may be
> surprising and annoying to users who did not want that.
Besides, I'm not able to imagine one scenario where this is the wrong
or annoying thing to do. Can you provide an example?
--
To unsubscribe from this list:
Jeff King wrote:
> It's not that it's not potentially useful. It's that it may be
> surprising and annoying to users who did not want that.
... but this is a new syntax, and doesn't break any existing
expectations. Why are you imagining what users will expect with a git
push -- master next; that
On Thu, Apr 11, 2013 at 03:12:20AM +0530, Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
> > My first hunch is not to like this, since it means
> >
> > git push -- master next
> >
> > might push to two different remotes and because it's not obvious
> > to me when it would be useful.
Jonathan Nieder wrote:
> My first hunch is not to like this, since it means
>
> git push -- master next
>
> might push to two different remotes and because it's not obvious
> to me when it would be useful.
Yes, it will push to two different remotes. And why is it not useful?
If we also h
Ramkumar Ramachandra wrote:
> If we're going to break "matching" anyway, let's break it fully.
Wait, let's not break anything. Instead, let us invent a new
push.default that does this ref-to-remote matching, and make git push
-- master push-implicit; consistent with that. Then "matching" can be
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>>git push master
>> ...
>> a) Error: you didn't tell me which remote to push to.
>> b) Just behave like "git push my-personal-remote master".
>> c) Behave like "git push origin master".
>
> Here, I'd argue for (d): push to branch.mas
Jonathan Nieder wrote:
> When people disagree about sane defaults, that's a sign that we didn't
> understand the problem well. Often more thinking can lead to a
> simpler answer.
Okay, let's see if we can all agree.
In a different email, you wrote:
>git push master
> ...
> a) Error: you
Jeff King wrote:
> On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
>> git push
>>
>> and "[push] default = upstream", then it is obvious what the user
>> wanted to happen. But what about when "[push] default = matching"?
>> Which of the following behaviors is correct?
>>
>>
Ramkumar Ramachandra wrote:
>My point is that we should have "sane"
> defaults, and fine-grained configurability so that uses who disagree
> can maintain their own configs.
I don't agree with this principle. I like a tool that behaves sanely
with little work and t
Junio C Hamano wrote:
> On the other hand, a good thing is that the remote.pushdefault makes
> perfect sense whether you use the upstream mode or the matching
> mode. I vaguely recall that I kept telling you that the overall
> default should be there and per-branch stuff can come later if/as
> nee
Jeff King wrote:
> But I think all of this discussion just reinforces my point. We do not
> have to agree on what the user intended. But the fact that we do not
> agree means that out of a sample size of 2 users, we have 2 different
> things the user expects to happen. If we choose a behavior and s
On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> >> Huh, why? Simply because he specified master alongside it? How can
> >> we infer what you said in a consistent system?
> >
> > T
Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> If we are not going to break the existing behavior, I think it can be
>> argued that consistency and simplicity of the rules is important, so the
>> user can predict what will happen. But the more we discuss, the more I
>> think we should simply cha
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
>> Huh, why? Simply because he specified master alongside it? How can
>> we infer what you said in a consistent system?
>
> That's kind of my point. Why would they put two refs together in a
> single push com
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Maybe. But no more so than the current:
>> >
>> > git push
>> >
>> > which may also push master and next to the same remote.
>>
>> I would argue that this was not really a problem i
Ramkumar Ramachandra writes:
> As the author of branch..pushremote, I apologize for not having
> caught this earlier. I've been using push.default = current for a
> long time, and don't often think about the other settings.
Possibly, but I do not know it is such a big issue.
On the other hand,
On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:
> > Right, the example above might include multiple remotes if pushremote is
> > respected. Or it might not come up with an answer at all for a tag.
> > If you do:
> >
> > git push -- v1.2.3 master
> >
> > where does v1.2.3 go
Jeff King writes:
> If we changed push.default=matching to ignore branch.*.remote, then that
> would be consistent, and would probably be safer over all. It is a
> regression, but I doubt that anybody was using branch.*.remote for this;
> it really only makes sense with the "upstream" mode.
True
On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Maybe. But no more so than the current:
> >
> > git push
> >
> > which may also push master and next to the same remote.
>
> I would argue that this was not really a problem in practice, until I
> intro
Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
>
>> Ramkumar Ramachandra wrote:
>> > git push -- master next; pushes to my current branch's
>> > branch..pushremote? Isn't that a disaster?
>>
>> Actually, branch..pushremote already breaks the current design
On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:
> I don't see a big problem here, actually. What's so wrong with
> branch..remote affecting what "git push" does? If
> branch.crazy-feature.remote is my-personal-remote and I run
>
> git push
>
> and "[push] default = upstr
Jeff King wrote:
> Maybe. But no more so than the current:
>
> git push
>
> which may also push master and next to the same remote.
I would argue that this was not really a problem in practice, until I
introduced branch..pushremote.
Let us imagine that I was working on artagnon/git.git (remote:
On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
> > git push -- master next; pushes to my current branch's
> > branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way, as Junio po
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> git push -- master next; pushes to my current branch's
>> branch..pushremote? Isn't that a disaster?
>
> Actually, branch..pushremote already breaks the current design
> in a way
I don't see a big problem here, actually. What's so wro
Ramkumar Ramachandra wrote:
> git push -- master next; pushes to my current branch's
> branch..pushremote? Isn't that a disaster?
Actually, branch..pushremote already breaks the current design
in a way, as Junio pointed out in a different email: a push.default
set to anything except "current" is
On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> >> > If branch.$name.remote is "when I am on this branch, I want to talk to
> >> > this remote", that rule is not be impacted by the presen
Ramkumar Ramachandra wrote:
> Otherwise, I think we're consistent. git push master; pushes the
> refspec master (with no explicit : counterpart) to the "default
> place to push to" (either depending on which branch I am, or global).
> I think Junio was mixing up refspecs with refs (branches, and h
Jeff King wrote:
> On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
>> > If branch.$name.remote is "when I am on this branch, I want to talk to
>> > this remote", that rule is not be impacted by the presence of refspecs
>> > at all.
>>
>> So running the above while on 'maint' will se
On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:
> > If branch.$name.remote is "when I am on this branch, I want to talk to
> > this remote", that rule is not be impacted by the presence of refspecs
> > at all.
>
> So running the above while on 'maint' will send master and next to
Jeff King writes:
>> With the branch.$name.remote, the user tells us "When I am on this
>> branch, I want to talk to this remote". When you did
>>
>> git push -- master next ;# case #4
>>
>> on branch maint, branch.maint.remote should not come into play.
>
> I understand that's your posit
On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:
> >
> >> Random idea: today you can do
> >>
> >>git push origin master; # push branch master to remote origin
> >>git push --multipl
On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote:
> > The missing case 4 is obviously:
> >
> > dst=missing, refs=present
> > ...
> > Do you want to explain your thinking? I'm guessing it has to do with the
> > fact that choosing branch.*.remote is about trying to push to the
> > co
Jeff King writes:
> On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:
>
>> Random idea: today you can do
>>
>> git push origin master; # push branch master to remote origin
>> git push --multiple origin korg; # push default refspec to 2 remotes
>
> Can we do "git push --
Jeff King writes:
> On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:
>
>> >git push -- master next; # push two refs to default remote
>>
>> ... or default "push remote" if there is one, I presume?
>>
>> As you are giving what to push, I am assuming that
>> branch.$name.remote
On Wed, Apr 10, 2013 at 06:52:51PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > git push --remote=host:some/path
> >
> > if we are willing to break the existing syntax. Though your proposal
> > does have the benefit of breaking only one particular syntax which is
> > (I'm guessing)
Jeff King wrote:
> git push --remote=host:some/path
>
> if we are willing to break the existing syntax. Though your proposal
> does have the benefit of breaking only one particular syntax which is
> (I'm guessing) less frequently used. But we'd still need the usual
> deprecation period, I think.
Jonathan Nieder wrote:
> git push origin korg -- master; # push master to 2 remotes
> git push -- master next; # push two refs to default remote
> git push origin -- master; # push master to origin, more explicitly
> git push origin korg --; # push default refspec to
On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:
> > git push -- master next; # push two refs to default remote
>
> ... or default "push remote" if there is one, I presume?
>
> As you are giving what to push, I am assuming that
> branch.$name.remote would not come into play in
On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:
> Random idea: today you can do
>
> git push origin master; # push branch master to remote origin
> git push --multiple origin korg; # push default refspec to 2 remotes
Can we do "git push --multiple" today? My git does
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> And I think now I agree that indeed is a sensible assumption. I am
>> not sure '-' is a good token for that, but I do not offhand think of
>> a reason why '-' would be a _bad_ token for that, either.
>
> Random idea: today you can do
>
>
Jonathan Nieder wrote:
> today you can do
>
> git push origin master; # push branch master to remote origin
> git push --multiple origin korg; # push default refspec to 2 remotes
Pretend I said "fetch". ;-)
--
To unsubscribe from this list: send the line "unsubscribe git"
Junio C Hamano wrote:
> And I think now I agree that indeed is a sensible assumption. I am
> not sure '-' is a good token for that, but I do not offhand think of
> a reason why '-' would be a _bad_ token for that, either.
Random idea: today you can do
git push origin master; # push bran
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> What is bad about saying "push origin ...the rest..."?
>
> I don't know which remote to push to: all I know is that the remote to
> push to is configured somewhere in the web of ...
Ahh, and then the recent triangular stuff makes it even wo
Ramkumar Ramachandra wrote:
> [...]
Let's not do anything too complex, and just aim for a more pleasant
experience for the simple case of force-pushing some refs without the
: counterpart. Then, all we have to do is verify that what is
specified is not a valid remote, and is not a valid local pat
Junio C Hamano wrote:
> What is bad about saying "push origin ...the rest..."?
I don't know which remote to push to: all I know is that the remote to
push to is configured somewhere in the web of branch.remote,
remote.pushdefault, and branch..pushremote, and I don't want to
have to figure that out
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> host:foo/bar (take my "host" branch, push it to their "foo/bar"
>> branch) could be tricky, no? It could be trying to go over the ssh
>> to "host" and access repository at $HOME/foo/bar. The git_connect()
>> call may even succeed and you c
Junio C Hamano wrote:
> host:foo/bar (take my "host" branch, push it to their "foo/bar"
> branch) could be tricky, no? It could be trying to go over the ssh
> to "host" and access repository at $HOME/foo/bar. The git_connect()
> call may even succeed and you cannot use the failure as a hint to
>
Ramkumar Ramachandra writes:
> Jeff King wrote:
>> So you would need some heuristics based on whether something was a valid
>> refspec, or could be a valid remote name or URL.
>
> All refspecs conform to a very simple format:
>
> quux
> +quux
> quux:baz
> +quux:baz
>
> All of them
Jeff King wrote:
> So you would need some heuristics based on whether something was a valid
> refspec, or could be a valid remote name or URL.
All refspecs conform to a very simple format:
quux
+quux
quux:baz
+quux:baz
All of them fail at git_connect(). The third and fourth are
"Holger Hellmuth (IKS)" writes:
> Am 19.03.2013 12:33, schrieb Duy Nguyen:
>> git push . foo:bar
>
> '.' has more like a "here" semantic, '..' might be a more fitting
> mnemonic here.
Heh, why not say "origin"? Or rename it to "o" if you like in your
own repository ;-)
--
To unsubscribe from t
Duy Nguyen writes:
> Assume that we agree on what remote is implied, we could simplify
> parsing by specifying the remote with "." (or something short and
> unambiguous). So the above command would become
>
> git push . foo:bar
That is an established idiom, a handy way to update your own bar
bra
Would it make sense to allow abbreviation similar to how git objects can
be abbreviated? This would mean origin usually could be spelled just o
--
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://
On Tue, Mar 19, 2013 at 6:53 PM, Ramkumar Ramachandra
wrote:
>> git push . foo:bar
>
> A URL may be a path to a git repository, and '.' is a valid path.
> Currently, 'git push .' seems to push to the current repository (what
> does that even mean?). For something truly unambiguous, we'll have to
Am 19.03.2013 12:33, schrieb Duy Nguyen:
git push . foo:bar
'.' has more like a "here" semantic, '..' might be a more fitting
mnemonic here.
--
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:
Duy Nguyen wrote:
> On Tue, Mar 19, 2013 at 12:08 AM, Jeff King wrote:
>>> Is there a reason for the remote not being optional, or are we just
>>> waiting for a patch? The only problem I can foresee is very minor:
>>> there is a ref with the same name as a remote; in this case, we'd have
>>> to s
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King wrote:
>> Is there a reason for the remote not being optional, or are we just
>> waiting for a patch? The only problem I can foresee is very minor:
>> there is a ref with the same name as a remote; in this case, we'd have
>> to specify both the remote a
On Tue, Mar 19, 2013 at 03:28:12PM +0530, Ramkumar Ramachandra wrote:
> > I think the ambiguity is a little more complex than that, because we
> > cannot enumerate the universe of all remotes. Keep in mind that we can
> > take either a configured remote or a URL (or ssh host). So what does:
> >
>
Jeff King wrote:
> On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:
>> Is there a reason for the remote not being optional, or are we just
>> waiting for a patch? The only problem I can foresee is very minor:
>> there is a ref with the same name as a remote; in this case, we'd
On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:
> This has irritated me for a long time. I often end up doing:
>
> $ git push master:master +pu:pu
Me too.
> Is there a reason for the remote not being optional, or are we just
> waiting for a patch? The only problem I
67 matches
Mail list logo
