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