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
