# Re: Idea for rebase strategy

- From: Junio C Hamano \<hidden\>
- Date: 2016-08-11 19:51:33 
- List: git
- Page: https://ratatoskr.run/git/2016/08/7689833
- Thread: https://ratatoskr.run/git/2016/08/7689833/t.md

```text
Andy Whitcroft [ref] writes:

>> 
>>        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.


```