On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote: > > I think that is doing the right thing for half of the problem. But > > there's something else funny where we do not include the "upstream" > > commits from the split history (i.e., we rebase onto nothing, > > whereas a normal "git rebase" with a split history will graft the two > > together). > > Let me ask to make sure I am understanding you correctly. Are you > referring to "split history" as the case where the commit graph has *two* > root commits? Yes, I mean two root commits. But especially when one is in the history to be rebased, and the other is in the "upstream" history. So as a concrete example, if I have this repo: git init >one && git add one && git commit -m one git checkout --orphan other git mv one two && git commit -m two and I do this: git rebase master I end up with a two-commit history, with "two" on top of "one". That makes sense to me. Similarly if I instead do: git rebase -i master the todo list has "pick two", and if I leave it as-is then I get the same history. But if I do: git rebase --preserve-merges master I end up with a single-commit history, with only commit "one". That's wrong, because it threw away the history on the "other" branch. If I apply the patch I showed earlier, then I get a single-branch history, but this time it contains only "two". That also seems wrong, because we didn't build on top of "master". I'd expect this command to give the same results as a non-merge-preserving rebase. Does that make more sense? -Peff
