@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@xxxxxxxxx> wrote: > > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > > > "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>". > > Correct. > > > "<branch>" is expected to be a > > branch name, not a symbolic ref to the branch like "HEAD". > > 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. >
