Re: "git rebase" behavior change in 2.26.0

[Elijah Newren <newren@gmail.com>]

On Tue, Mar 24, 2020 at 10:40 PM Jeff King <peff@peff.net> wrote:
>
> On Tue, Mar 24, 2020 at 08:38:04PM -0700, Norbert Kiesel wrote:
>
> > I track an upstream repo with "pull.rebase = true" where I do a `git
> > pull` followed by a `git log -p ORIG_HEAD..` for a branch to see
> > changes since the last "pull".  I normally do not commit to this
> > branch and thus this normally is a "fast-forward" merge.
> >
> > Starting with 2.26 this no longer works because ORIG_HEAD is always
> > set to HEAD after my `git pull`.
> >
> > I track other prances from the same repo where I do local changes and
> > then want the `git pull --rebase` and I thus do not want to
> > give up on the `pull.rebase = true` configuration.
>
> I can imagine this is related to the switch to the "merge" backend for
> git-pull, which may be more eager to overwrite ORIG_HEAD. Perhaps try:
>
>   git -c rebase.backend=apply pull
>
> and see if that behaves differently.
>
> I tried to reproduce what you're seeing, but my recipe doesn't seem to
> show any difference between the two versions:
>
> -- >8 --
> #!/bin/sh
>
> rm -rf repo
>
> git init -q repo
> cd repo
> echo content >base && git add base && git commit -q -m base
> git clone -q . dst
> echo content >new && git add new && git commit -q -m new
>
> cd dst
> git rev-parse HEAD >.git/ORIG_HEAD
> echo before: $(git log -1 --oneline ORIG_HEAD)
> git -c pull.rebase=true pull -q ..
> echo after: $(git log -1 --oneline ORIG_HEAD)
> -- 8< --
>
> We don't seem to touch ORIG_HEAD in either case. But maybe a more
> complex set of pulled commits would trigger it?

I can't duplicate either.  I suspected that perhaps rebase.autoStash
might help cause it to happen if you had local changes, but I didn't
succeed in reproducing with that either.

Norbert: Any ideas what you may be doing differently to trigger this?
And does it still happen with rebase.backend=apply, as Peff asked
about?


Elijah