Possible git bug

[Wesley Schwengle <wesley@schwengle.net>]

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

-- 
Wesley Schwengle
E: wesley@schwengle.net