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

[Jeff King <peff@peff.net>]

On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote:

> > 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?

Yes, I mean two root commits. But especially when one is in the history
to be rebased, and the other is in the "upstream" history.

So as a concrete example, if I have this repo:

  git init
  >one && git add one && git commit -m one
  git checkout --orphan other
  git mv one two && git commit -m two

and I do this:

  git rebase master

I end up with a two-commit history, with "two" on top of "one". That
makes sense to me. Similarly if I instead do:

  git rebase -i master

the todo list has "pick two", and if I leave it as-is then I get the
same history. But if I do:

  git rebase --preserve-merges master

I end up with a single-commit history, with only commit "one". That's
wrong, because it threw away the history on the "other" branch.

If I apply the patch I showed earlier, then I get a single-branch
history, but this time it contains only "two". That also seems wrong,
because we didn't build on top of "master". I'd expect this command to
give the same results as a non-merge-preserving rebase.

Does that make more sense?

-Peff