"git rebase" behavior change in 2.26.0

"git rebase" behavior change in 2.26.0

[Norbert Kiesel]

Hi,

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.

Re: "git rebase" behavior change in 2.26.0

[Jeff King]

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

Re: "git rebase" behavior change in 2.26.0

[Elijah Newren]

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

Re: "git rebase" behavior change in 2.26.0

[Norbert Kiesel]

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:
>
> 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

Re: "git rebase" behavior change in 2.26.0

[Norbert Kiesel]

Here is a concrete example:

lt-nkiesel:~Platform(nextrelease)% git -c rebase.backend=merge -c
pull.rebase=false -c branch.nextrelease.rebase=true pull
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), 279 bytes | 279.00 KiB/s, done.
From msgit.rnd.metricstream.com:platform/Platform7
   d008080d3f2..db4042856da  nextrelease -> origin/nextrelease
Updating d008080d3f2..db4042856da
Fast-forward
 modules/bpcsfw/src/main/java/com/metricstream/systemi/client/servlet/servant/BaseViewController.java
| 54 +++++++++++++++++++++++++-----------------------------
 modules/bpcsfw/src/main/java/com/metricstream/util/HttpUtils.java
                               |  5 +++++
 2 files changed, 30 insertions(+), 29 deletions(-)
Successfully rebased and updated refs/heads/nextrelease.
lt-nkiesel:~Platform(nextrelease)% git rev-parse ORIG_HEAD
db4042856da8338f183c831fca92cf63da7988bd
lt-nkiesel:~Platform(nextrelease)% git rev-parse HEAD
db4042856da8338f183c831fca92cf63da7988bd
lt-nkiesel:~Platform(nextrelease)%

As you can see, git said "Fast-forward" (i.e. no need to rebase) but
nevertheless after that pull ORIG_HEAD is identical to HEAD

Re: "git rebase" behavior change in 2.26.0

[Elijah Newren]

Ooh, the plot thickens...

On Wed, Mar 25, 2020 at 6:46 PM Norbert Kiesel <nkiesel@gmail.com> wrote:
>
> Here is a concrete example:
>
> lt-nkiesel:~Platform(nextrelease)% git -c rebase.backend=merge -c
> pull.rebase=false -c branch.nextrelease.rebase=true pull

So pull.rebase is false for the general case, but it should be true
when on the nextrelease branch.  Your prompt seems to imply you are on
the nextrelease branch, but I'm not so sure because...

> remote: Enumerating objects: 1, done.
> remote: Counting objects: 100% (1/1), done.
> remote: Total 1 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (1/1), 279 bytes | 279.00 KiB/s, done.
> From msgit.rnd.metricstream.com:platform/Platform7
>    d008080d3f2..db4042856da  nextrelease -> origin/nextrelease
> Updating d008080d3f2..db4042856da
> Fast-forward

"Fast-forward" is a message from builtin/merge.c, it implies that
rebase is not invoked at all.  (rebase with the merge backend calls
merge-recursive.c, not builtin/merge.c)  This suggests that
pull.$branch.rebase isn't working as we intended.

>  modules/bpcsfw/src/main/java/com/metricstream/systemi/client/servlet/servant/BaseViewController.java
> | 54 +++++++++++++++++++++++++-----------------------------
>  modules/bpcsfw/src/main/java/com/metricstream/util/HttpUtils.java
>                                |  5 +++++
>  2 files changed, 30 insertions(+), 29 deletions(-)

Diffstats are also off by default for rebases, so unless you've set
rebase.stat in some config somewhere, this also suggests that a merge
was used.


Now, when I try to duplicate, just for fun I added some 'die("You ran
a merge!")' and 'die("You ran a rebase!")' lines early in
builtin/{merge,rebase}.c, just so I could verify what was run.  Then I
tried to use a command line similar to yours:

$ git -c rebase.backend=merge -c pull.rebase=false -c
branch.master.rebase=true pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 250 bytes | 250.00 KiB/s, done.
From /home/newren/floss/git/testing/pull-rebase-orig-head/repo
   c911eef..2ccdb90  master     -> origin/master
fatal: You ran a merge!
fatal: You ran a rebase!


Say, WAT?!?  This attempted to run both a merge and a rebase?  That
appears to be yet another bug.

> Successfully rebased and updated refs/heads/nextrelease.
> lt-nkiesel:~Platform(nextrelease)% git rev-parse ORIG_HEAD
> db4042856da8338f183c831fca92cf63da7988bd
> lt-nkiesel:~Platform(nextrelease)% git rev-parse HEAD
> db4042856da8338f183c831fca92cf63da7988bd
> lt-nkiesel:~Platform(nextrelease)%
>
> As you can see, git said "Fast-forward" (i.e. no need to rebase) but
> nevertheless after that pull ORIG_HEAD is identical to HEAD

When I remove the die() calls that I added, here's what I see:

$ git -c rebase.backend=merge -c pull.rebase=false -c
branch.master.rebase=true pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 251 bytes | 251.00 KiB/s, done.
From /home/newren/floss/git/testing/pull-rebase-orig-head/repo
   100c273..c911eef  master     -> origin/master
Updating 100c273..c911eef
Fast-forward
 numbers | 1 +
 1 file changed, 1 insertion(+)
Current branch master is up to date.

$ git log --oneline --reverse
9691d52 initial
1d5a4c1 add another
0da5805 add another
ccea292 add another
100c273 add another
c911eef (HEAD -> master, origin/master, origin/HEAD) add another

$ git rev-parse --short ORIG_HEAD
100c273

In other words, ORIG_HEAD does not match HEAD, it correctly points at
the old commit.  So, we found a couple bugs, but I still can't
duplicate the bug you're reporting.  What else is different about your
setup?  What's in your .git/config, and in your $HOME/.gitconfig?
What hooks do you have setup in .git/hooks/ -- do any of them do a
reset --hard?

Re: "git rebase" behavior change in 2.26.0

[Elijah Newren]

On Wed, Mar 25, 2020 at 8:37 PM Elijah Newren <newren@gmail.com> wrote:
> Now, when I try to duplicate, just for fun I added some 'die("You ran
> a merge!")' and 'die("You ran a rebase!")' lines early in
> builtin/{merge,rebase}.c, just so I could verify what was run.  Then I
> tried to use a command line similar to yours:
>
> $ git -c rebase.backend=merge -c pull.rebase=false -c
> branch.master.rebase=true pull
> remote: Enumerating objects: 5, done.
> remote: Counting objects: 100% (5/5), done.
> remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
> Unpacking objects: 100% (3/3), 250 bytes | 250.00 KiB/s, done.
> From /home/newren/floss/git/testing/pull-rebase-orig-head/repo
>    c911eef..2ccdb90  master     -> origin/master
> fatal: You ran a merge!
> fatal: You ran a rebase!
>
>
> Say, WAT?!?  This attempted to run both a merge and a rebase?  That
> appears to be yet another bug.

From git-pull.c:

    ...
        if (is_descendant_of(merge_head, list)) {
            /* we can fast-forward this without invoking rebase */
            opt_ff = "--ff-only";
            ret = run_merge();
        }
    }
    ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);

Perhaps that comment should read:

   /* we can fast-forward this using merge and avoid rebase...but then
run rebase afterward anyway! */

Whoops.  Perhaps fixing this is a good micro-project candidate?  Too small?

Re: "git rebase" behavior change in 2.26.0

[Jeff King]

On Wed, Mar 25, 2020 at 11:32:31PM -0700, Elijah Newren wrote:

> > Say, WAT?!?  This attempted to run both a merge and a rebase?  That
> > appears to be yet another bug.
> 
> From git-pull.c:
> 
>     ...
>         if (is_descendant_of(merge_head, list)) {
>             /* we can fast-forward this without invoking rebase */
>             opt_ff = "--ff-only";
>             ret = run_merge();
>         }
>     }
>     ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);
> 
> Perhaps that comment should read:
> 
>    /* we can fast-forward this using merge and avoid rebase...but then
> run rebase afterward anyway! */
> 
> Whoops.  Perhaps fixing this is a good micro-project candidate?  Too small?

Good find. :) Looks like this is due to a6d7eb2c7a (pull: optionally
rebase submodules (remote submodule changes only), 2017-06-23) which
changed the early return to "ret =".

I think it would be an OK size for a micro-project, but it seems like a
bug which we may want fixed sooner rather than waiting for somebody to
pick it up from the micro-project pile.

Or perhaps not. AFAICT this has been there for 2+ years without anybody
noticing.

-Peff

Re: "git rebase" behavior change in 2.26.0

[Norbert Kiesel]

I ran a "pull" today morning w/o sufficient coffee and thus forgot to
disable the "pull.rebase" and was bitten by that again.  Here is what
I see when using "GIT_TRACE2=1 git -c pull.rebase=true pull
--ff-only":
...
10:54:50.578673 run-command.c:735                 child_start[2] git
merge --ff-only FETCH_HEAD
10:54:50.580385 common-main.c:48                  version 2.26.0
10:54:50.580404 common-main.c:49                  start
/usr/lib/git-core/git merge --ff-only FETCH_HEAD
10:54:50.580587 repository.c:130                  worktree
/home/nkiesel/work/Platform
10:54:50.580785 git.c:440                         cmd_name merge (pull/merge)
Already up to date.
10:54:50.589803 git.c:674                         exit elapsed:0.009835 code:0
10:54:50.589827 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.009874 code:0
10:54:50.590887 run-command.c:990                 child_exit[2]
pid:939370 code:0 elapsed:0.012205
10:54:50.590919 run-command.c:735                 child_start[3] git
rebase --onto d0527895a4df44f00162b68011b803e597fd400f
d0527895a4df44f00162b68011b803e597fd400f
10:54:50.592396 common-main.c:48                  version 2.26.0
10:54:50.592412 common-main.c:49                  start
/usr/lib/git-core/git rebase --onto
d0527895a4df44f00162b68011b803e597fd400f
d0527895a4df44f00162b68011b803e597fd400f
10:54:50.592568 repository.c:130                  worktree
/home/nkiesel/work/Platform
10:54:50.592714 git.c:440                         cmd_name rebase (pull/rebase)
10:54:50.593142 builtin/rebase.c:1669             cmd_mode undefined
10:54:50.614154 run-command.c:735                 child_start[0] git
checkout d0527895a4df44f00162b68011b803e597fd400f
10:54:50.678813 run-command.c:990                 child_exit[0]
pid:939392 code:0 elapsed:0.064656
Successfully rebased and updated refs/heads/nextrelease.
10:54:50.697724 git.c:674                         exit elapsed:0.105715 code:0
10:54:50.697734 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.105729 code:0
10:54:50.698307 run-command.c:990                 child_exit[3]
pid:939371 code:0 elapsed:0.107373
10:54:50.698343 git.c:674                         exit elapsed:5.904200 code:0
10:54:50.698354 trace2/tr2_tgt_normal.c:123       atexit elapsed:5.904211 code:0

I would argue that "--ff-only" would mean to never rebase, but clearly
git runs a rebase of HEAD onto HEAD and i assume by that setting
ORIG_HEAD to HEAD as colloquial damage.

Re: "git rebase" behavior change in 2.26.0

[Elijah Newren]

On Fri, Mar 27, 2020 at 11:01 AM Norbert Kiesel <nkiesel@gmail.com> wrote:
>
> I ran a "pull" today morning w/o sufficient coffee and thus forgot to
> disable the "pull.rebase" and was bitten by that again.  Here is what
> I see when using "GIT_TRACE2=1 git -c pull.rebase=true pull
> --ff-only":
> ...
> 10:54:50.578673 run-command.c:735                 child_start[2] git
> merge --ff-only FETCH_HEAD
> 10:54:50.580385 common-main.c:48                  version 2.26.0
> 10:54:50.580404 common-main.c:49                  start
> /usr/lib/git-core/git merge --ff-only FETCH_HEAD
> 10:54:50.580587 repository.c:130                  worktree
> /home/nkiesel/work/Platform
> 10:54:50.580785 git.c:440                         cmd_name merge (pull/merge)
> Already up to date.
> 10:54:50.589803 git.c:674                         exit elapsed:0.009835 code:0
> 10:54:50.589827 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.009874 code:0
> 10:54:50.590887 run-command.c:990                 child_exit[2]
> pid:939370 code:0 elapsed:0.012205
> 10:54:50.590919 run-command.c:735                 child_start[3] git
> rebase --onto d0527895a4df44f00162b68011b803e597fd400f
> d0527895a4df44f00162b68011b803e597fd400f
> 10:54:50.592396 common-main.c:48                  version 2.26.0
> 10:54:50.592412 common-main.c:49                  start
> /usr/lib/git-core/git rebase --onto
> d0527895a4df44f00162b68011b803e597fd400f
> d0527895a4df44f00162b68011b803e597fd400f
> 10:54:50.592568 repository.c:130                  worktree
> /home/nkiesel/work/Platform
> 10:54:50.592714 git.c:440                         cmd_name rebase (pull/rebase)
> 10:54:50.593142 builtin/rebase.c:1669             cmd_mode undefined
> 10:54:50.614154 run-command.c:735                 child_start[0] git
> checkout d0527895a4df44f00162b68011b803e597fd400f
> 10:54:50.678813 run-command.c:990                 child_exit[0]
> pid:939392 code:0 elapsed:0.064656
> Successfully rebased and updated refs/heads/nextrelease.
> 10:54:50.697724 git.c:674                         exit elapsed:0.105715 code:0
> 10:54:50.697734 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.105729 code:0
> 10:54:50.698307 run-command.c:990                 child_exit[3]
> pid:939371 code:0 elapsed:0.107373
> 10:54:50.698343 git.c:674                         exit elapsed:5.904200 code:0
> 10:54:50.698354 trace2/tr2_tgt_normal.c:123       atexit elapsed:5.904211 code:0
>
> I would argue that "--ff-only" would mean to never rebase, but clearly
> git runs a rebase of HEAD onto HEAD and i assume by that setting
> ORIG_HEAD to HEAD as colloquial damage.

When I run the exact same command in my test repo, I see:

[newren@tiger clone]$ GIT_TRACE2=1 git -c pull.rebase=true pull --ff-only
11:13:16.376197 common-main.c:48                  version 2.26.0
11:13:16.376228 common-main.c:49                  start
/home/newren/floss/git/git -c pull.rebase=true pull --ff-only
11:13:16.376457 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.376605 git.c:440                         cmd_name pull (pull)
11:13:16.378095 run-command.c:735                 child_start[0] git
merge-base --fork-point refs/remotes/origin/master master
11:13:16.380766 run-command.c:990                 child_exit[0]
pid:1247445 code:0 elapsed:0.002662
11:13:16.380827 run-command.c:735                 child_start[1] git
fetch --update-head-ok
11:13:16.382368 common-main.c:48                  version 2.26.0
11:13:16.382388 common-main.c:49                  start
/home/newren/floss/git/git fetch --update-head-ok
11:13:16.382493 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.382579 git.c:440                         cmd_name fetch (pull/fetch)
11:13:16.383141 run-command.c:735                 child_start[0]
'git-upload-pack
'\''/home/newren/floss/git/testing/pull-rebase-orig-head/repo/'\'''
11:13:16.386079 common-main.c:48                  version 2.26.0
11:13:16.386096 common-main.c:49                  start
git-upload-pack
/home/newren/floss/git/testing/pull-rebase-orig-head/repo/
11:13:16.386119 git.c:440                         cmd_name upload-pack
(pull/fetch/upload-pack)
11:13:16.388828 run-command.c:735                 child_start[0] git
pack-objects --revs --thin --stdout --progress --delta-base-offset
--include-tag
remote: 11:13:16.390448 common-main.c:48                  version 2.26.0
remote: 11:13:16.390464 common-main.c:49                  start
/home/newren/floss/git/git pack-objects --revs --thin --stdout
--progress --delta-base-offset --include-tag
remote: 11:13:16.390554 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/repo/.git
remote: 11:13:16.390670 git.c:440                         cmd_name
pack-objects (pull/fetch/upload-pack/pack-objects)
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
11:13:16.392266 run-command.c:735                 child_start[1] git
unpack-objects --pack_header=2,3
remote: 11:13:16.392261 git.c:674                         exit
elapsed:0.002147 code:0
remote: 11:13:16.392274 trace2/tr2_tgt_normal.c:123       atexit
elapsed:0.002162 code:0
11:13:16.392507 run-command.c:990                 child_exit[0]
pid:1247449 code:0 elapsed:0.003677
11:13:16.393548 common-main.c:48                  version 2.26.0
11:13:16.393560 common-main.c:49                  start
/home/newren/floss/git/git unpack-objects --pack_header=2,3
11:13:16.393691 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.393832 git.c:440                         cmd_name
unpack-objects (pull/fetch/unpack-objects)
Unpacking objects: 100% (3/3), 252 bytes | 252.00 KiB/s, done.
11:13:16.394854 git.c:674                         exit elapsed:0.001576 code:0
11:13:16.394865 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.001588 code:0
11:13:16.395069 run-command.c:990                 child_exit[1]
pid:1247450 code:0 elapsed:0.002802
11:13:16.395157 git.c:674                         exit elapsed:0.009406 code:0
11:13:16.395176 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.009429 code:0
11:13:16.395394 run-command.c:990                 child_exit[0]
pid:1247447 code:0 elapsed:0.012252
11:13:16.395476 run-command.c:735                 child_start[2] git
rev-list --objects --stdin --not --all --quiet --alternate-refs
11:13:16.396725 common-main.c:48                  version 2.26.0
11:13:16.396738 common-main.c:49                  start
/home/newren/floss/git/git rev-list --objects --stdin --not --all
--quiet --alternate-refs
11:13:16.396855 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.396927 git.c:440                         cmd_name rev-list
(pull/fetch/rev-list)
11:13:16.397946 git.c:674                         exit elapsed:0.001493 code:0
11:13:16.397959 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.001511 code:0
11:13:16.398176 run-command.c:990                 child_exit[2]
pid:1247451 code:0 elapsed:0.002694
From /home/newren/floss/git/testing/pull-rebase-orig-head/repo
   2ccdb90..2c21563  master     -> origin/master
11:13:16.399051 run-command.c:735                 child_start[3] git gc --auto
11:13:16.400295 common-main.c:48                  version 2.26.0
11:13:16.400309 common-main.c:49                  start
/home/newren/floss/git/git gc --auto
11:13:16.400413 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.400508 git.c:440                         cmd_name gc (pull/fetch/gc)
11:13:16.400708 git.c:674                         exit elapsed:0.000696 code:0
11:13:16.400719 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.000708 code:0
11:13:16.400909 run-command.c:990                 child_exit[3]
pid:1247452 code:0 elapsed:0.001853
11:13:16.400939 git.c:674                         exit elapsed:0.018943 code:0
11:13:16.400958 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.018962 code:0
11:13:16.401150 run-command.c:990                 child_exit[1]
pid:1247446 code:0 elapsed:0.020317
11:13:16.401475 run-command.c:735                 child_start[2] git
merge --ff-only FETCH_HEAD
11:13:16.402718 common-main.c:48                  version 2.26.0
11:13:16.402735 common-main.c:49                  start
/home/newren/floss/git/git merge --ff-only FETCH_HEAD
11:13:16.402854 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.402953 git.c:440                         cmd_name merge (pull/merge)
Updating 2ccdb90..2c21563
Fast-forward
11:13:16.404582 run-command.c:735                 child_start[0] git gc --auto
11:13:16.406161 common-main.c:48                  version 2.26.0
11:13:16.406178 common-main.c:49                  start
/home/newren/floss/git/git gc --auto
11:13:16.406301 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.406395 git.c:440                         cmd_name gc (pull/merge/gc)
11:13:16.406663 git.c:674                         exit elapsed:0.000929 code:0
11:13:16.406680 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.000950 code:0
11:13:16.406934 run-command.c:990                 child_exit[0]
pid:1247454 code:0 elapsed:0.002345
 numbers | 1 +
 1 file changed, 1 insertion(+)
11:13:16.407320 git.c:674                         exit elapsed:0.004889 code:0
11:13:16.407336 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.004907 code:0
11:13:16.407556 run-command.c:990                 child_exit[2]
pid:1247453 code:0 elapsed:0.006076
11:13:16.407617 run-command.c:735                 child_start[3] git
rebase --onto 2c21563a2dd61db0a502100ce1da5b6b0ecf8337
2c21563a2dd61db0a502100ce1da5b6b0ecf8337
11:13:16.409886 common-main.c:48                  version 2.26.0
11:13:16.409917 common-main.c:49                  start
/home/newren/floss/git/git rebase --onto
2c21563a2dd61db0a502100ce1da5b6b0ecf8337
2c21563a2dd61db0a502100ce1da5b6b0ecf8337
11:13:16.410166 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.410402 git.c:440                         cmd_name rebase (pull/rebase)
11:13:16.410705 builtin/rebase.c:1669             cmd_mode undefined
Current branch master is up to date.
11:13:16.412385 run-command.c:735                 child_start[0] git gc --auto
11:13:16.413967 common-main.c:48                  version 2.26.0
11:13:16.413983 common-main.c:49                  start
/home/newren/floss/git/git gc --auto
11:13:16.414075 repository.c:130                  worktree
/home/newren/floss/git/testing/pull-rebase-orig-head/clone
11:13:16.414152 git.c:440                         cmd_name gc (pull/rebase/gc)
11:13:16.414363 git.c:674                         exit elapsed:0.000748 code:0
11:13:16.414375 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.000763 code:0
11:13:16.414607 run-command.c:990                 child_exit[0]
pid:1247456 code:0 elapsed:0.002218
11:13:16.414690 git.c:674                         exit elapsed:0.005410 code:0
11:13:16.414720 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.005441 code:0
11:13:16.414925 run-command.c:990                 child_exit[3]
pid:1247455 code:0 elapsed:0.007305
11:13:16.414984 git.c:674                         exit elapsed:0.039375 code:0
11:13:16.415023 trace2/tr2_tgt_normal.c:123       atexit elapsed:0.039415 code:0

So there is no checkout for me; and while it's a useful hint it's not
yet clear to me why you have one.  Anyway, on my side:

$ git log --oneline --reverse; git rev-parse --short ORIG_HEAD
9691d52 initial
1d5a4c1 add another
0da5805 add another
ccea292 add another
100c273 add another
c911eef add another
2ccdb90 add another
2c21563 (HEAD -> master, origin/master, origin/HEAD) add another
2ccdb90


So, I'll repeat the same questions I asked last time, and see if you
will answer them this time:

What's in your .git/config, and in your $HOME/.gitconfig?  (Or maybe
just the output of 'git config --list'?)
What hooks do you have setup in .git/hooks/?

Re: "git rebase" behavior change in 2.26.0

[Elijah Newren]

On Fri, Mar 27, 2020 at 11:34 AM Elijah Newren <newren@gmail.com> wrote:
>
> On Fri, Mar 27, 2020 at 11:01 AM Norbert Kiesel <nkiesel@gmail.com> wrote:
> >
...
> What's in your .git/config, and in your $HOME/.gitconfig?  (Or maybe
> just the output of 'git config --list'?)
> What hooks do you have setup in .git/hooks/?

After some off-thread discussion due to concerns with sharing his
configuration globally...

Ahah, so I can duplicate when using both pull.rebase=true and
rebase.autosquash=true.  rebase.autosquash in the rebase code sets
allow_preemptive_ff to 0, meaning it disables rebase from
fast-forwarding.  That would have been fine if we only ran a rebase,
but we ran both a merge and a rebase and thus updated ORIG_HEAD
*twice*.  So, the "extra" bug I found upthread (pull runs both merge
and rebase for a fast-forward) isn't an extra bug but is *the* bug in
question.  It's been with us for a few years as Jeff pointed out, but
just was uncovered due to the other recent 2.26 changes.  Patch
incoming soon.