On Fri, Aug 8, 2025 at 3:15 PM Julia Evans via GitGitGadget
[off-list ref] wrote:

Thanks for the review comments, here are the new changes which:

 * make the intro to the man page less dry, with the suggested wording
 * clarify the merge conflict resolution explanation & fix the HTML
   formatting issues
 * move the explanation of the git rebase <upstream> <branch> syntax up into
   the intro

I'm still curious about the intention for the git rebase master topic
syntax, since I'd never heard of it before. Is it just to save on typing,
since it's fewer characters than git switch topic and then git rebase
master? I ask because someone mentioned to me on Mastodon
(https://hachyderm.io/@simontatham/114988051822317920) that they sometimes
use git rebase HEAD main as part of their workflow, which is not equivalent
to git checkout main && git rebase HEAD. That made me think that there might
be some broader intent to enable rebases that wouldn't otherwise be possible
without that syntax.

I think the intent really is "shortcut." It's existed since the first
version of rebase (59e6b23ace ([PATCH] git-rebase-script: rebase local
commits to new upstream head., 2005-06-25),
https://lore.kernel.org/git/7v4qboejp6.fsf_-_@assigned-by-dhcp.cox.net/ (local)).
I didn't look too closely at that mailing list thread for any
justification of the shortcut, though.

The example mentioned on Mastodon is still a shortcut, it's just more
like a function than a macro (that is, the arguments are evaluated
first, then the shortcut applied):

    git rebase HEAD main

becomes (in shell syntax)

    head=$(git rev-parse HEAD)
    git switch --detach main
    git rebase $head

rather than

    git switch --detach main
    git rebase HEAD # too late, HEAD has changed