Re: Bug with rebase and commit hashes

John Cai [off-list ref] writes:

quoted

I hit this in production on git 2.30.2 (debian bullseye), but reproduced
locally using the latest git main, which is git version 2.35.1.415.gc2162907.
In both cases I wiped my user gitconfig, so I'm using only the defaults. (If
it helps: with my rebase.autosquash = true, the bad case above does not behave
badly and leaves me in detached head as I'd expect.) It's totally possible
this isn't _meant_ to work, in which case I think the docs could use an
update.

A quick bisect session leads us to 176f5d96 (built-in rebase
--autostash: leave the current branch alone if possible,
2018-11-07), but I do not know how much commonality exists in the
current code (read: we may well have inherited the bug from there,
or we rewrote it completely away but reinvented the same bug in the
current code).

with this test script dropped as t/x9999-c.sh

--- >8 ---

#!/bin/sh

test_description='rebase???'

. ./test-lib.sh

test_expect_success setup '
	git init &&
	>file &&
	git add file &&
	git commit -m initial &&
	git checkout -b side &&
	echo >>file &&
	git commit -a -m side &&
	git checkout master &&
	git tag hold
'

test_expect_success rebase '
	git checkout -B master hold &&
	git rev-parse master >pre &&
	git rebase $(git rev-parse master) $(git rev-parse side) &&
	git rev-parse master >post &&
	test_cmp pre post
'

test_done

--- 8< ---

and this as "git bisect run ./runme.sh" script:

--- >8 ---

#!/bin/sh

make -j16 NO_OPENSSL=Yes CFLAGS="-g -O" || exit 125
cd t && sh -v ./x9999-c.sh -i -v

--- 8< ---

The NO_OPENSSL thing is there only because I started bisecting from
an ancient version that no longer compiles out of the box in my
environment.