Re: is rebase the same as merging every commit?

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Jun 27, 2008, 06:30 UTC
Message-ID: <vpqfxqz5qzj.fsf@bauges.imag.fr>
In-Reply-To: <willow-jeske-01l78ZaEFEDjCZEG>

"David Jeske" <jeske@willowmail.com> writes:

Show 22 quoted lines

> Rebasing is described in the docs I've read as turning this: (sorry for the
> dots)
>
> ..........A---B---C topic
> ........./
> ....D---E---F---G master
>
> Into this:
>
> ...................A'--B'--C' topic
> ................../
> .....D---E---F---G master
>
> If I understand it right (and that's a BIG if), it's the same as doing a merge
> of C into G where every individual commit in the C-line is individually
> committed into the new C' line.
>
> ...........-------------A---B---C
> ........../            /   /   /
> ........./        /---A'--B'--C'  topic
> ......../        /
> ....D---E---F---G - master

I'd draw that the other way:

  ...........---------A---B---C
  ........../          \   \   \
  ........./        /---A'--B'--C'  topic
  ......../        /
  ....D---E---F---G - master

> (1) Is the above model a valid explanation?

Sounds correct to me.

> (2) From the documentation diagrams, it looks like the rebased A' has only (G)
> as a parent, not (A,G). If this is the case, why?

Well, one could imagine a "rebase keeping ancestry" command, which would keep A and G (indeed, you can do that by hand with multiple calls to "merge"). The advantage being that further merges involving both A and A' have better chance to succeed.

But philosophy of "rebase" is different: the idea is that you usually rebase your private branches before submission, and the guys you submit to are interested in your changes (i.e. the patch serie diff(G,A'), diff(A',B'), ...), not the way you got this patch serie.

So, discarding this ancestry information is a bit like discarding your *~ files (or whatever backup files your editor might create) after some time: it has been valuable information, but at some point, it becomes noise you don't want to hear.

> (i.e. not connecting those nodes throws away useful information)

For the use-cases where this information is useful, "rebase" is not for you. Indeed, in these cases, a plain "merge" is usually what you want.

> (3) If it only has (G) as a parent, does the rebase explicitly remove the
> source A,B,C nodes from the repository?

Most commands, and this includes rebase, are "add-only". The objects will remain unreferenced and will be pruned by the next git gc --prune. Unreferenced objects do not harm, they just eat your disk space.

Well, that was a first approximation. Indeed, the reflog still references C, see "git reflog". For example, after the rebase, if you realize that you actually didn't want this rebase, you can still "git reset --hard HEAD@{1}" or something like that.

-- 
Matthieu