On Tue, Mar 24, 2020 at 10:40 PM Jeff King <peff@xxxxxxxx> 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
