Re: "git rebase" behavior change in 2.26.0

[Elijah Newren <newren@gmail.com>]

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?