Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull <otherRepositoryUrl>

[Jeff King <peff@peff.net>]

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