Possible git bug

Hello,

I'm running into a weird issue with git at the moment and I'm wondering if this is a bug. I have a small reproduction path:

$ mkdir reproduction $ cd reproduction $ git init . $ echo "commit a" > file.txt $ git commit -m "First commit" file.txt $ echo "commit b" >> file.txt $ git commit -m "Second commit" file.txt

$ git switch -c foo $ echo "commit c" >> file.txt" $ git commit -m "Third commit" file.txt $ git branch --set-upstream-to=master

$ git status On branch foo Your branch is ahead of 'master' by 1 commit.

$ git switch master $ git merge foo $ git reset --hard HEAD^ $ git switch foo Switched to branch 'foo' Your branch is ahead of 'master' by 1 commit.

$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset' 5f427e3 Third commit 03ad791 Second commit 411e6d4 First commit

$ git rebase master $ git status On branch foo Your branch is up to date with 'master'.

$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset' 03ad791 Second commit 411e6d4 First commit

I do not expect to lose the commits from foo, it seems the ref of master doesn't get updated after a reset.

I didn't lose any work because I pushed my work to a remote and can still get it from there (and git reflog would also reach my code). It is rather surprising to see this kind of behavior.

I'm running: $ git --version git version 2.33.0.363.g4c719308ce

But I also got this behavior with the git shipped with Debian: $ /usr/bin/git --version git version 2.32.0

Cheers, Wesley