Jeff King p...@peff.net 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
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 work
on
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 'something
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
Ramkumar Ramachandra artag...@gmail.com 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).
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.
Why?
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
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
configured
On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
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
the
Ramkumar Ramachandra wrote:
Otherwise, I think we're consistent. git push master; pushes the
refspec master (with no explicit :dst 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
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 presence of
Ramkumar Ramachandra wrote:
git push -- master next; pushes to my current branch's
branch.name.pushremote? Isn't that a disaster?
Actually, branch.name.pushremote already breaks the current design
in a way, as Junio pointed out in a different email: a push.default
set to anything except
Ramkumar Ramachandra wrote:
Ramkumar Ramachandra wrote:
git push -- master next; pushes to my current branch's
branch.name.pushremote? Isn't that a disaster?
Actually, branch.name.pushremote already breaks the current design
in a way
I don't see a big problem here, actually. What's so
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.name.pushremote? Isn't that a disaster?
Actually, branch.name.pushremote already breaks the current design
in a way, as Junio
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.name.pushremote.
Let us imagine that I was working on artagnon/git.git (remote:
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.name.remote affecting what git push does? If
branch.crazy-feature.remote is my-personal-remote and I run
git push
and [push] default = upstream,
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.name.pushremote? Isn't that a disaster?
Actually, branch.name.pushremote already breaks the current design
in
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
introduced
Jeff King p...@peff.net 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
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? To
Ramkumar Ramachandra artag...@gmail.com writes:
As the author of branch.name.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.
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 in practice, until I
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 command?
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 change the
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?
That's kind
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 say
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
needed,
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 that
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?
a) Error: you
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
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.master.pushremote/
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
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 had
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.
Yes, it
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
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:
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. Why
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 annoying
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
Ramkumar Ramachandra artag...@gmail.com 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
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 artag...@gmail.com 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
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.name.pushremote, and I don't want to
have to figure that
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
:dst counterpart. Then, all we have to do is verify that what is
specified is not a valid remote, and is not a valid local
Ramkumar Ramachandra artag...@gmail.com 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
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 branch
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 in
the
Jonathan Nieder jrnie...@gmail.com 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
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 not
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 this
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 have
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:
git
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King p...@peff.net 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
Duy Nguyen wrote:
On Tue, Mar 19, 2013 at 12:08 AM, Jeff King p...@peff.net 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
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
On Tue, Mar 19, 2013 at 6:53 PM, Ramkumar Ramachandra
artag...@gmail.com 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,
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
Duy Nguyen pclo...@gmail.com 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
Holger Hellmuth (IKS) hellm...@ira.uka.de 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
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 can
63 matches
Mail list logo
