Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-12-02 Thread Junio C Hamano
Peter Wu writes: > On Saturday 29 November 2014 13:31:18 Philip Oakley wrote: >> From: "Peter Wu" >> > 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 (m

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-12-02 Thread Peter Wu
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote: > From: "Peter Wu" > > 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

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-29 Thread Philip Oakley
From: "Peter Wu" 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 form the whole set

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-25 Thread Peter Wu
On Monday 24 November 2014 21:19:16 Junio C Hamano wrote: > On Mon, Nov 24, 2014 at 9:01 PM, Jeff King 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 think that t

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-25 Thread Peter Wu
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"? Expla

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Jeff King
On Mon, Nov 24, 2014 at 08:55:13PM -0800, Junio C Hamano wrote: > Jeff King 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

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Junio C Hamano
Jeff King 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 most

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Jeff King
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 re

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Peter Wu
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 rem

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Junio C Hamano
Jeff King 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 weird, what

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Jeff King
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

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Peter Wu
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. > > >

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Jeff King
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 incompatibiliti

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Peter Wu
On Monday 24 November 2014 14:04:07 Junio C Hamano wrote: > Peter Wu 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 w

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Junio C Hamano
Peter Wu 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 this?

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-24 Thread Peter Wu
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(

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Peter Wu
On Wednesday 19 November 2014 13:18:56 Junio C Hamano wrote: > Junio C Hamano writes: > > Jeff King 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 like this, instead? > >

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Junio C Hamano
Junio C Hamano writes: > Jeff King 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

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Junio C Hamano
Peter Wu 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 myself. > > Wh

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Junio C Hamano
Jeff King 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 is only ne

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Peter Wu
On Wednesday 19 November 2014 12:29:47 Junio C Hamano wrote: > Jeff King 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 wh

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Peter Wu
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 >

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Junio C Hamano
Jeff King 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 implies to m

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Jeff King
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

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Peter Wu
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 plac

Re: [RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Jeff King
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 n

[RFC] [PATCH] remote: add new --fetch option for set-url

2014-11-19 Thread Peter Wu
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: