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

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Junio

On 01/09/2024 16:42, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> "<branch>" is expected to be a
>> branch name, not a symbolic ref to the branch like "HEAD".
> 
> I question the correctness of this, though.

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

> 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.j

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