Re: Idea for rebase strategy

From: Junio C Hamano <junkio@cox.net>
Date: Nov 27, 2006, 09:26 UTC
Message-ID: <7vfyc5i6k4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <456AA9B2.8050409@shadowen.org>

Andy Whitcroft <apw@shadowen.org> writes:

Show 13 quoted lines

>> 
>>        A---B---C---D---E topic
>>       /       /
>>   ---X---o---Y---Z master
>>                   \
>>                    A'--B'--C'--D' topic'
>
> Interestingly this trivial situation seems to works pretty much as is.
> A "git rebase --onto master X topic" (at least in my trivial test case)
> replayed A and B, squashed C as a noop, and copied D and E.  I did not
> need any information from the reflog.  Of course the reflog is a good
> way to find X as its first transaction but I did not need it to drive
> replay.

That is only because the pictures are showing the degenerated case for simplicity, and the defect that the current rebase does not even look at any merges is hidden by the fact that the merge in the example C becomes no-op in the rebased history. C could be somewhere not between X and Z, in which case replaying the merge becomes necessary. Also when following from E to traverse down the history of topic, at point C, you need to tell which of B or Y are on the topic, and that's where you would rely on ref-log.