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@xxxxxxxxxxxxx
