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

> On Oct 27, 2010 1:36pm, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Eugene Sajine wrote:
>>
>>
>>
>> > Thanks for prompt answer. But let me clarify:
>>
>> >
>>
>> > When you do pull git performs:
>>
>> >
>>
>> > fetch of the remote branch to the FETCH_HEAD
>>
>> > and then merge of FETCH_HEAD into the local branch
>>
>> >
>>
>> > What I'm saying is that your local branch should be rebased on top of
>>
>> > FETCH_HEAD instead
>>
>> >
>>
>> > 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