Re: Re: Why the default action for pull is merge, but not rebase?

On Wed, Oct 27, 2010 at 1:50 PM,  [off-list ref] wrote:

On Oct 27, 2010 1:36pm, Jonathan Nieder [off-list ref] wrote:

quoted

Eugene Sajine wrote:

quoted

Thanks for prompt answer. But let me clarify:

quoted

quoted

When you do pull git performs:

quoted

quoted

fetch of the remote branch to the FETCH_HEAD

quoted

and then merge of FETCH_HEAD into the local branch

quoted

quoted

What I'm saying is that your local branch should be rebased on top of

quoted

FETCH_HEAD instead

quoted

quoted

In this case there is no such thing as "often rebased public branch".

Ah, but there is.



Imagine you are Junio and just received a pull request from Pat.

Then you might try:



 $ git pull pat for-junio



which will do all the fetching and merging magic that "git pull"

is known for.  Now if pat's for-junio branch is based on the tip

of your current branch, this will be a fast-forward and it doesn't

matter whether you merge or rebase.  But what if there are some

intervening commits?



 $ git pull eric for-junio

 $ git pull pat for-junio



If this pull were the rebasing kind, the result would be for Eric's

commits to be rewritten based on Pat's.

Oh, I see. In this case you're right.
My scenario is probably making more sense for the "centralized approach",
where the exchange goes via some blessed bare repo on the server.
So, I just have to run git pull --rebase to get my scenario working, right?


Thanks!
Eugene

Actually it seems that it will not work as i would expect...
git pull --rebase is going to rebase the upstream on top of my local
branch, right? Is this really intended behavior? Shouldn't it rebase
my local on top of the upstream instead?

Thanks,
Eugene