`git rebase (--no-fork-point) --onto=<newbase> [<upstream> [<branch>]]` leaves HEAD detached and *HEAD not moved when <branch> is exactly `HEAD`

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

cd '/'; cd '/'; rm --force --recursive -- './test_git'; mkdir "$_"; cd "$_"; mkdir --parents -- './server' './client'; git -C './server' init --bare './repo.git' echo '1' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" echo '2' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" git -C './server/repo.git' log --graph --all --patch

git -C './client' clone '../server/repo.git' './repo' branch_default_path="$(git -C './client/repo' symbolic-ref HEAD)" branch_default_name="${branch_default_path#'refs/heads/'}" echo '3' >'./client/repo/file'; git -C './client/repo' add './file'; git -C './client/repo' commit -m "$((++number))" git -C './client/repo' log --graph --all --patch

git -C './server/repo.git' reset --soft HEAD~1 echo '4' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" git -C './server/repo.git' log --graph --all --patch

git -C './client/repo' fetch --all git -C './client/repo' log --graph --all --patch git -C './client/repo' -c 'core.editor=cat' rebase --onto=HEAD@{upstream} --interactive "$(git -C './client/repo' merge-base --fork-point HEAD@{upstream} HEAD)" HEAD git -C './client/repo' log --graph --all --patch echo '5' >'./client/repo/file'; git -C './client/repo' add './file'; git -C './client/repo' -c 'core.editor=:' rebase --continue git -C './client/repo' log --graph --all --patch git -C './client/repo' checkout -B "$branch_default_name" git -C './client/repo' log --graph --all --patch

What did you expect to happen? (Expected behavior)

HEAD points to GIT_DEFAULT_BRANCH and GIT_DEFAULT_BRANCH points to tip of origin's GIT_DEFAULT_BRANCH when rebase completes.

What happened instead? (Actual behavior)

HEAD is detached and *HEAD is not moved when rebase completes, so `git checkout -B` is needed.

What's different between what you expected and what actually happened?

Anything else you want to add:

Replacing `HEAD` with branch name (`"$(git -C './client/repo' branch --show-current)"`) works around the problem. cd '/'; cd '/'; rm --force --recursive -- './test_git'; mkdir "$_"; cd "$_"; mkdir --parents -- './server' './client'; git -C './server' init --bare './repo.git' echo '1' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" echo '2' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" git -C './server/repo.git' log --graph --all --patch

git -C './client' clone '../server/repo.git' './repo' echo '3' >'./client/repo/file'; git -C './client/repo' add './file'; git -C './client/repo' commit -m "$((++number))" git -C './client/repo' log --graph --all --patch

git -C './server/repo.git' reset --soft HEAD~1 echo '4' >'./file'; git --git-dir='./server/repo.git' --work-tree='.' add './file'; git --git-dir='./server/repo.git' --work-tree='.' commit -m "$((++number))" git -C './server/repo.git' log --graph --all --patch

git -C './client/repo' fetch --all git -C './client/repo' log --graph --all --patch git -C './client/repo' -c 'core.editor=cat' rebase --onto=HEAD@{upstream} --interactive "$(git -C './client/repo' merge-base --fork-point HEAD@{upstream} HEAD)" "$(git -C './client/repo' branch --show-current)" git -C './client/repo' log --graph --all --patch echo '5' >'./client/repo/file'; git -C './client/repo' add './file'; git -C './client/repo' -c 'core.editor=:' rebase --continue git -C './client/repo' log --graph --all --patch

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info]
git version:
git version 2.46.0.windows.1
cpu: x86_64
built from commit: 2e6a859ffc0471f60f79c1256f766042b0d5d17d
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.9.0
OpenSSL: OpenSSL 3.2.2 4 Jun 2024
zlib: 1.3.1
uname: Windows 10.0 22631
compiler info: gnuc: 14.1
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

[Enabled Hooks] not run from a git repository - no hooks to show

On 01/09/2024 12:02, Han Jiang wrote:

"git rebase <upstream> <branch>" is designed to switch to a different branch before rebasing it. If you do not want to switch branches you should use "git rebase <upstream>". "<branch>" is expected to be a branch name, not a symbolic ref to the branch like "HEAD".

This is working as expected.

"git checkout HEAD" is a no-op so "git rebase <upstream> HEAD" is behaving differently to "git checkout HEAD && git rebase <upstream>". We could look at changing that but it would be a breaking change for anyone relying on the current behavior to detach HEAD before rebasing.

Best Wishes

Phillip

Phillip Wood <phillip.wood123@gmail.com> writes:

Correct.

I question the correctness of this, though. The "what to rebase" argument can be any arbitrary commit-ish, and if it is a name of a local branch, that branch is rebased. If it is not, the HEAD is detached and that detached HEAD state is rebased. The latter is handy when you are unsure if you want to really touch the branch. i.e. "git rebase master topic^0"---this way you'd end up on a detached HEAD that shows what would happen if you really rebased "topic" branch, but if you do not like the result, you can just discard the state by e.g., checking out some branch, and you do not even contaminate the reflog of the "topic" branch with the record of this failed exeriment.

I have a mild suspicion that the "rebase" command might have changed its behaviour since the days back when it was implemented as a shell script, when the "what to rebase" argument is HEAD, as the most natural implementation to do this "optionally first switch to it when the argument is given" in the scripted Porcelain is to actually run "git checkout HEAD", which should be a somewhat noisy no-op. Apparently today's "git rebase" does not work that way and seems to detach HEAD instead and then rebases it. As you said, that is the behaviour most users are familiar with and it is probably too late to change, even if (I didn't check) an ancient version of "rebase" did not work that way and instead rebased the current branch.

Thanks.

@Phillip Wood @Junio C Hamano I finally got it. Thank you both for your explanation!

On Mon, Sep 2, 2024 at 3:42 AM Junio C Hamano <gitster@pobox.com> wrote:

Hi Junio

On 01/09/2024 16:42, Junio C Hamano wrote:

Yes as you explain below, it is a bit of an over simplification

 >

It appears to have changed in 0cb06644a5 (rebase [--onto O] A B: omit needless checkout, 2008-03-15). That also changed the reflog messages written by "git rebase <upstream> <branch>" so that "git checkout @{n}" does not see the new branch being checked out.

Best Wishes

Phillip

Phillip Wood <phillip.wood123@gmail.com> writes:

Thanks for digging. Even if we now know that it was a regression in the early times of the current code, it is way too old to change it now.

Unless we want to do so at a major version bump, but I do not know if this is big enough to worth writing a release note entry for. Users who do want to run a trial rebase of the current branch on a detached HEAD have all been already using HEAD^0 as the <branch> argument and they have been fine without complaints.

Making it consistent in the opposite direction by changinging "git checkout HEAD" to detach HEAD is unthinkable. So what we have is fine, I would think.

Thanks.