Hi Peff, On Fri, 23 Feb 2018, Jeff King wrote: > 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. Your analysis makes sense to me. Please note, though, that I would not consider myself a guru on preserve-merges. I think this mode is broken by design (you can blame me if you want). Ciao, Dscho
