Andrew Wong <andrew.w@xxxxxxxxxxx> writes:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html