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
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
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
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
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
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
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
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
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
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
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
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.
> >
>
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
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
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?
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(
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?
> >
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
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
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
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
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
>
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
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
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
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
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:
27 matches
Mail list logo