On Fri, Dec 18, 2015 at 06:05:49PM +0000, John Keeping wrote: > On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > > John Keeping <john@xxxxxxxxxxxxx> writes: > > > > > It seems that the problem is introduces by --preserve-merges (and > > > -Xsubtree causes something interesting to happen as well). I see the > > > following behaviour: > > > > Thanks for narrowing this down! Is it possible this is actually a > > cherry-pick problem since --preserve-merges forces rebase to use > > cherry-pick? > > I'm pretty sure this a result of the code in git-rebase--interactive.sh > just below the comment "Watch for commits that have been dropped by > cherry-pick", which filters out certain commits. However, I'm not at > all familiar with the --preserve-merges code in git-rebase so I could be > completely wrong. I've traced through git-rebase--interactive.sh and I can see what's happening here now. The problematic code is around the handling of the "rewritten" directory. In --preserve-merges mode, we write the SHA1 of the "onto" commit into rewritten and then add any commits descended from it along the first-parent path that we have identified as candidates for being rebased. This allows us to identify commits that have been merged in and remove them from the rebase instruction list. Because the right-hand commit in this case is disjoint from "onto", we end up dropping everything at this point. The --root option fixes this because instead of preserving just "onto", it adds all of the commits given by: git merge-base --all $orig_head $upstream Since the disjoint history causes the root commit to be rewritten, I think requiring --root for this case to work is reasonable. However, I'm not sure we should add it automatically. It may be better to detect that there is no common history and die if --root has not been given. -- 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