On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote: > > 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). 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). I haven't figured that part out. But I do kind of wonder if we should simply punt early and say "what you're doing is crazy and unsupported". After all, the only known case of this was somebody doing it accidentally. -Peff
