Re: [PATCH] fetch: add new fetch.default configuration

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 19, 2013, 12:37 UTC
Message-ID: <CAMP44s0p067aR4XKqrNimdsp2GrYa42mdnarTZoSGFuNdgy1dA@mail.gmail.com>
In-Reply-To: <CALkWK0=poS43aGYuMzEP9K7e0P0khFRnzQxihtgAvh3rtb9Mdw@mail.gmail.com>

On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 7 quoted lines

> My itch is very simple.
>
> Felipe Contreras wrote:
>> % git checkout fc/remote/hg-next
>> % git rebase -i # rebase to master
>
> % git pull # I want: pull from origin

Then do 'git pull origin', 'fc/remote/hg-next' has *nothing* to do with origin.

>> % git checkout fc/remote/hg-notes
>> % git rebase -i # rebase to fc/remote/hg-next
>
> % git pull # I want: pull from ram

Ditto.

>> % git checkout fc/remote/hg-gitifyhg-compat
>> % git rebase -i # rebase to fc/remote/hg-notes
>
> % git pull # I want: pull from felipe

Ditto.

> With your series, rebase works and I like that.  But, by specifying
> branch.<name>.remote as '.',

I'm not doing that *GIT* is doing that.

What does this throw? % git checkout --track -b foo master % git config branch.foo.remote

> I've essentially lost a way to specify a
> remote I want.  Why can't I have both?

You haven't lost anything. The upstream is 'branch.x.remote'+'branch.x.merge', and it remains so before and after this patch. You can set 'branch.x.remote' to whatever you want.

-- 
Felipe Contreras