On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically
Peter Wu pe...@lekensteyn.nl writes:
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both?
From: Peter Wu pe...@lekensteyn.nl
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically speaking it is
correct
as fetch and push are both partitions that
On Monday 24 November 2014 23:08:26 Jeff King wrote:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about just --push,
--fetch, and --both? Explain the
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
On Mon, Nov 24, 2014 at 9:01 PM, Jeff King p...@peff.net wrote:
We could also stop making push fall back to fetch. But I think people
would find that irritating.
The common case is probably having the same fetch and push URL, so I
ping?
I asked around and the people who know of `git remote` fell in these two
categories:
- those who know of this bug and then first set the fetch URL and
then the push URL.
- those who did not expect the current behavior.
The command 'git remote set-url NAME URL' reads as set the URL(s)
Peter Wu pe...@lekensteyn.nl writes:
I propose to add the option --fetch next to --push with the meaning set
the fetch/push URL of remote NAME to URL. Then --fetch --push means
set the fetch and push URL of remote NAME to URL.
What would (and should) the configuration look like after you did
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
Peter Wu pe...@lekensteyn.nl writes:
I propose to add the option --fetch next to --push with the meaning set
the fetch/push URL of remote NAME to URL. Then --fetch --push means
set the fetch and push URL of remote NAME to URL.
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
A new option --fetch introducing a different behaviour is
perfectly fine; existing users who are not using it will not be
harmed by sudden behaviour change.
As stated before, I took care to avoid backwards incompatibilities. The
On Monday 24 November 2014 17:22:44 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
A new option --fetch introducing a different behaviour is
perfectly fine; existing users who are not using it will not be
harmed by sudden behaviour change.
As stated
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
Right. My original complaint was only that --fetch is not as
orthogonal to --push (and an optionless set-url) as it could be. I
think the alternatives for going forward are basically:
1. Name it something besides --fetch (but
Jeff King p...@peff.net writes:
My complaint is that you have three possible options to provide: --push,
--fetch, or no option at all. And --fetch sometimes behaves like no
option, and sometimes not. Which is the confusing/non-orthogonal part.
I can understand that --fetch sounds a bit
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
I can understand that --fetch sounds a bit weird, what about this
natural translation:
git remote: set the URL (only the fetch one) for NAME to URL
git remote set-url
On Tue, Nov 25, 2014 at 12:27:31AM +0100, Peter Wu wrote:
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
I can understand that --fetch sounds a bit weird, what about this
natural translation:
git remote: set the
Jeff King p...@peff.net writes:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about just --push,
--fetch, and --both?
I think that is the set that is
On Mon, Nov 24, 2014 at 08:55:13PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a both option, since it made it more
clear that is not what no-option means. So what about
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever was in place for the push URL.
This patch adds support for a '--fetch' option which implements that use
case in a backwards compatible way:
On Wed, Nov 19, 2014 at 04:18:02PM +0100, Peter Wu wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever was in place for the push URL.
Isn't that what:
git remote set-url foo
On Wednesday 19 November 2014 14:08:00 Jeff King wrote:
On Wed, Nov 19, 2014 at 04:18:02PM +0100, Peter Wu wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for update fetch URL and
leave whatever was in place for
On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
git remote set-url --push gh $(git config remote.gh.url)
git remote set-url gh new-fetch-url
Indeed, and not having a push URL is not uncommon (that is, always the
case when a new remote is added or just cloned). Compare the
Jeff King p...@peff.net writes:
I dunno. I guess that is more convenient, but it seems like a lot of
code for a very marginal use case. But more importantly, I'm a little
worried that the presence of --fetch creates confusion about what
set-url without a --fetch or --push does. That is, it
On Wednesday 19 November 2014 15:17:21 Jeff King wrote:
On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
git remote set-url --fetch new-fetch-url
This is less verbose and is much more intuitive.
I agree your suggestion is a nicer way to do this. I'm just not sure
that this
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I dunno. I guess that is more convenient, but it seems like a lot of
code for a very marginal use case. But more importantly, I'm a little
worried that the presence of --fetch creates confusion
Jeff King p...@peff.net writes:
But here you do not have a pushurl defined in the first place. So I
guess this is really just a shortcut for swapping the two, like:
git remote set-url --push gh $(git config remote.gh.url)
git remote set-url gh new-fetch-url
It seems that this swapping
Peter Wu pe...@lekensteyn.nl writes:
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote:
...
Yes, the semantics the updated code gives feel very strange. I
wouldn't be able to write a three-line summary in the release notes
to advertise what good this new feature brings to users
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
But here you do not have a pushurl defined in the first place. So I
guess this is really just a shortcut for swapping the two, like:
git remote set-url --push gh $(git config remote.gh.url)
git remote set-url gh
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
If you are fetching from somebody else and then pushing into your
own publishing repository (i.e. fork of that upstream), why isn't
the sequence of event
27 matches
Mail list logo
