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

[Eugene Sajine <euguess@gmail.com>]

On Wed, Oct 27, 2010 at 12:57 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Eugene Sajine wrote:
>
>>               So, why not to rebase?
>
> An interesting question.
>
> Rebasing results in untested commits.  If this is a patch series
> for submission, that's fine, because you will be extensively
> testing each patch anyway or indicating to reviewers that that
> needs to be done (right?).  But if it's a long-lived branch then
> such repeated testing work can be a serious hassle.
> https://git.wiki.kernel.org/index.php/GitFaq#What_is_the_difference_between_a_merge_and_a_rebase.3F
>
> A public branch that is regularly rebased is hard to follow
> ("git log foo@{1}..foo") and build on.
> http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase
>
> Code consumers often want clean history, but that really means
> (a) clean and (b) history.
> http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744
>
> Hope that helps.
>

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".

if the history got diverged then pull will result in new state that
should be tested anyway, so why not to rebase local branch on top of
the upstream instead of merging upstream into local branch?

i'm not saying to rebase the upstream published branch on top of the
local changes - that's NO-NO I'm aware of

thanks,
Eugene