I have to wait for a few hours to see more changes in that branch that showed this behavior. I tried with this branch just now and my repo is in sync with upstream. Nevertheless, I see messages about operations for both backends now for `git pull` which I don't remember seeing before: % git status --untracked-files=no On branch nextrelease Your branch is up to date with 'origin/nextrelease'. nothing to commit (use -u to show untracked files) % git -c rebase.backend=merge pull Already up to date. Successfully rebased and updated refs/heads/nextrelease. % git -c rebase.backend=apply pull Already up to date. First, rewinding head to replay your work on top of it... Fast-forwarded nextrelease to d008080d3f2dc5a9af30067f705a3cb26ed847b3. % Why is git doing anything if the branch is already up-to-date? The commit it ff to is the HEAD of that branch so I don't think anything is really changing. Also, if I use `-c pull.rebase=false` I see what I think is the 2.25 behavior % git status --untracked-files=no On branch nextrelease Your branch is up to date with 'origin/nextrelease'. nothing to commit (use -u to show untracked files) % git -c rebase.backend=merge -c pull.rebase=false pull Already up to date. % git -c rebase.backend=apply -c pull.rebase=false pull Already up to date. I had `pull.rebase=true` configured for quite some time now. And yes, I should set it for just this "never push" branch instead of for all branches. I just tried with `-c pull.rebase=false -c branch.nextrelease.rebase=true` and that shows the same behavior as `-c pull.rebase=true`. One potential difference: I have tons of untracked files in my working directory. Could that make a difference? On Wed, Mar 25, 2020 at 2:39 PM Norbert Kiesel <nkiesel@xxxxxxxxx> wrote: > > I will try to reproduce and will report back. > > On Wed, Mar 25, 2020 at 2:21 PM Elijah Newren <newren@xxxxxxxxx> wrote: >> >> 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
