On Sun, May 19, 2013 at 7:26 AM, Ramkumar Ramachandra
<artag...@gmail.com> 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


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


> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to