On Fri, Feb 23, 2018 at 06:29:55AM +0100, "Marcel 'childNo͡.de' Trautwein" wrote: > shows me a quite different behavior, so solely rebase not seems the full problem > BUT > `--rebase=preserve` will .. o’man , really, is this intended? Yeah, the bug seems to be in --preserve-merges. Here's an easier reproduction: git init >one && git add one && git commit -m one git checkout --orphan other git mv one two && git commit -m two git rebase --preserve-merges master at which point we've dropped commit "two" and its files entirely. I don't know much about how preserve-merges works. It looks like in the loop around git-rebase--interactive.sh:931 that we mark commit "two" with preserve=t, and so we _don't_ add it to the list of commits to pick. I think that stems from the fact that it has no parent marked to be rewritten. So something like this helps: diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 81c5b42875..71e6cbb388 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -921,15 +921,20 @@ else if test -z "$rebase_root" then preserve=t + p= for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-) do if test -f "$rewritten"/$p then preserve=f fi done + if test -z "$p" + then + preserve=f + fi else preserve=f fi if test f = "$preserve" Because it at least adds "two" to the list of commits to pick. But oddly, it picks it directly as a root commit again. Whereas a rebase without --preserve-merges (and even "-i") picks it on top of commit "one" (which is what I'd expect). +cc Dscho, as the --preserve-merges guru. -Peff
