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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]