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