Re: "git rebase" behavior change in 2.26.0
Ooh, the plot thickens...
On Wed, Mar 25, 2020 at 6:46 PM Norbert Kiesel <nkiesel@gmail.com> wrote:
Show 5 quoted lines
>
> 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...
Show 8 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 9 quoted lines
> 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?
