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

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 28, 2010, 06:17 UTC
Message-ID: <20101028061707.GB3009@atjola.homenet>
In-Reply-To: <AANLkTimoSH2C4dBDDN1KMaFAp_nwAtLy5_uNFfiuz5GR@mail.gmail.com>

On 2010.10.27 13:21:18 -0400, Eugene Sajine wrote:

Show 33 quoted lines

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

How do you know? Right before the pull, you could have run push, so you would be rebasing a 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?

Merging results in either 0 (fast-forward) or 1 (mege) new commit, rebase results in 0-N new commits.

Let's say you have this history:

A---B---C (master)
 \
  D---E---F (topic)

If you merge topic to master, you get:

A---B---C---M (master)
 \         /
  D---E---F (topic)

So there's one new commit to test.

If you instead rebase topic onto master, you get:

          D'--E'--F' (topic)
         /
A---B---C (master)
 \
  D---E---F

So there are three new commits, all untested. And it's not enough to test just F'. Even if that is ok, D' and E' might still be broken.

Simple example:
 - In A there was a function "int foo(int a)".
 - In D you added a call to that function.
 - In F you removed that call.
 - B changed the function signature to "int foo(int a, int b)"

The new F' commit will be fine, as there is no call to that function. But D' and E' are broken as they still contains the call to foo with just one argument.

HTH Björn