Andy Whitcroft <apw@xxxxxxxxxxxx> 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. - 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