Re: is rebase the same as merging every commit?

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 27, 2008, 01:08 UTC
Message-ID: <7vvdzvn0ql.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vzlp7n1j4.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

> "David Jeske" <jeske@willowmail.com> writes:
> ...
>> (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?  (i.e. not
>> connecting those nodes throws away useful information)
>
> You would rebase ONLY WHEN the project as the whole (either "other people
> in the project", or "yourself down the road one year from now") is
> interested mostly in the progress of 'master' D-E-F-G, and nobody cares
> whether you developed your A (or B or C) on top of E or G.  So the answer
> is definite "no" --- the line you drew between A and A' is a useless
> information.  Nobody cares you did it first on top of E but then you have
> redone the patches based on G (because things changed between E and G).

The last sentence came out in somewhat inappropriate way.

	In the situation "rebase" (which is a way to help you pretend you
	did not start building on a stale codebase) is appropriate, nobody
	wants to know you did it first on E

is what I meant. More importantly, _you_ do not want anybody to know. That is the whole reason you would rebase.

With that clarification in mind, the explanation would flow more smoothly to this part...

> If the fact that parallel developments have happened is important, instead
> of the second picture like you drew, you will just do the real merge
> naturally to create a merge "M" like the picture I drew above.

So you have a choice between merging and rebasing. And your extra parents goes against the reason you chose rebasing in the first place. That is why we do not record the original parents anywhere.