Re: "git rebase" behavior change in 2.26.0

From: Norbert Kiesel <nkiesel@gmail.com>
Date: Mar 26, 2020, 01:37 UTC
Message-ID: <CAM+g_Nvt3X4d5cjKajzDOcoDgNS4bVkj3a0KvVm4yDEW-J7v2w@mail.gmail.com>
In-Reply-To: <CAM+g_NtHC5ukU3jchVfud_H_m_h29UQ8vmwQoND8s_Q9Hv70Fg@mail.gmail.com>

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@gmail.com> wrote:

Show 62 quoted lines

>
> I will try to reproduce and will report back.
>
> On Wed, Mar 25, 2020 at 2:21 PM Elijah Newren <newren@gmail.com> wrote:
>>
>> 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