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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Peff,

On Wed, 28 Feb 2018, Jeff King wrote:

> 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).

Let me ask to make sure I am understanding you correctly. Are you
referring to "split history" as the case where the commit graph has *two*
root commits?

If so: when you perform a merge-preserving rebase, then those two root
commits will be recreated as new root commits, by design.

The non-merge-preserving mode cannot create two root commits, as it does
not allow for introducing merge commits (and you'd need that to combine
the two strands).

It is quite possible that I misunderstand completely, though. Care to
enlighten me?

Ciao,
Dscho