Re: [BUG] rebase -p loses commits

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2011, 00:54 UTC
Message-ID: <7vpqnii1sx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DD1C277.9070605@sohovfx.com>

Andrew Wong <andrew.w@sohovfx.com> writes:

Show 16 quoted lines

> On 05/16/2011 04:36 PM, Junio C Hamano wrote:
>>     F---*  feature
>>    /   /
>>   B---M    master
>>
>> But what does it mean to rebase that on top of master, preserving merges
>> in the first place? You are already on top of 'master' and '*' itself
>> should be what you should get, no?  IOW, shouldn't you already be
>> up-to-date?
>>    
> Since preserve-merge uses the interactive-rebase, I think
> interactive-rebase should still pick the merge commit, which will then
> be consistent with what's happening if we rebase onto "F". So, without
> knowing whether "F" or "M" is the first-parent, I think
> interactive-rebase onto "F" and onto "M" should have the same
> effect. i.e. interactive-rebase picks the merge commit

I agree that changing the behaviour based on the "first-ness" of the parent is a wrong thing to do in general. But even then, I have a more fundamental question.

What does rebasing that '*' on top of M really mean?

Does it mean this?

    F---*                 F'--*'
   /   /   --->          /   /
  B---M             B---M---/

In other words:

	Take all the commits reachable from '*', exclude the ones that are
	ancestors of M, and make sure that commit that corresponds to each
	of the remaining commits (in this case, F' and *' correspond to F
	and * respectively) are decendants of M, and reconstruct the graph
	preserving the parenthood relationship between corresponding
	commits.

I would understand why some project may want to require you to rebase to the tip to keep a linear history, and the above sentence would be the right specification for linearizing rebase except for the "and reconstruct the graph" part.

But the above "preserving" rewrite does not even preserve the topology of the graph (the original * is a true merge between two forks, but *' is not) to begin with. Also, if you want to _usefully_ place F' on top of M, such a rewrite should resolve possible conflicts that was resolved at * in the original graph at F' anyway, which would mean that the resulting *' should become a totally empty commit.

Why would anybody want to do such a thing to begin with?